问题
Is there a general rule of thumb as to how many classes, interfaces etc should go in to a given name space before the items should be further classfied in to a new name space? Like a best practice or a community preference? Or is this all personal preference?
namespace: MyExample.Namespace
interface1
interface2
interface3
interface4
interface5
interface6
interface7
interface8
interface9
Or
namespace: MyExample.Namespace.Group1
interface1
interface2
interface3
namespace: MyExample.Namespace.Group2
interface4
interface5
interface6
namespace: MyExample.Namespace.Group3
interface7
interface8
interface9
回答1:
I have not seen any rule of thumb at any reliable source but there are a few common preferences that I haven seen while working with most developers. There are a few things that help you make the namespaces.
- Domain of the class
- Is it a class or an interface (I have seen some developers prefer namespaces like ShopApp.Model.Interfaces ). Works really well if your interfaces are some service or data contract.
- Dont have namespaces that are too deep, 3 (.) is enough. More than that may get annoying.
- Be open to reorganize namespace if at anytime u feel it has become illogical or hard to manage.
- Do not create namespaces just for the sake of it.
Happy Coding!!!
回答2:
If building a library or a module, it is generally better to use only one namespace, since the primary function of a namespace is to avoid name collisions and you have the control over what names get assigned to classes and interfaces.
回答3:
I don't know of any rule of thumb for the number of items, but those kinds of rules tend to be over-generalized garbage anyway. Make sure there is a logical connection between items in the same namespace. If a namespace is getting too crowded (unlikely, I hope), or the things in the namespace are only loosely related at best, consider breaking it up into multiple namespaces.
回答4:
I would argue that the namespace hierarchy should only be gouverned by considerations of design and the hierarchy of the model/API.
If one namespace sports huge number of unrelated classes, rethink your design.
Contrary to what Andrew said, I would not worry about namespaces containing few classes – although it's of course true that the hierarchy should only be as fine-grained as needed to express the design.
On the other hand, I find it completely reasonable for a namespace to contain only one highly special class, or perhaps just a very small set of types, of which one encodes the task and the others provide an API (exceptions, enums for arguments …).
As an example, take System.Text.RegularExpressions (in .NET). Granted, slightly more than one class, but only just.
回答5:
It is generally considered bad form to have a small number of classes in a namespace. I have always attributed this to the fact that many namespaces leads to confusion.
I would suggest that you break the classes into logical namespaces being as reasonable and practical as possible. However if you end up with only one or two classes per namespace then you might be fracturing too much and should think about consolidating.
来源：https://stackoverflow.com/questions/431911/namespace-rule-of-thumb