命名空间经验法则

在项目应该进一步分类到新的名称空间之前，有一个关于有多少类，接口等应该进入给定名称空间的一般规则？像最佳做法还是社区偏好？或者这是所有的个人偏好？命名空间经验法则

namespace: MyExample.Namespace 
interface1 
interface2 
interface3 
interface4 
interface5 
interface6 
interface7 
interface8 
interface9

或者

namespace: MyExample.Namespace.Group1 
interface1 
interface2 
interface3 
namespace: MyExample.Namespace.Group2 
interface4 
interface5 
interface6 
namespace: MyExample.Namespace.Group3 
interface7 
interface8 
interface9

来源

2009-01-10 Frank V

我还没有看到任何可靠的来源的经验法则，但有一些共同的偏好，我曾与大多数开发人员一起看过。有几件事可以帮助你制作命名空间。

域类
的它是一个类或接口（我已经看到了一些开发人员喜欢的命名空间像ShopApp.Model.Interfaces）。如果你的界面是一些服务或数据合同，那么工作得很好。
不要命名空间太深，3（。）就够了。不止这些可能会让人讨厌。
如果您觉得它已经变得不合逻辑或难以管理，请随时重新组织命名空间。
不要为了它而创建名称空间。

快乐编码！

来源

2009-01-10 23:21:08 Perpetualcoder

它通常被认为是不好的形式有一个命名空间的少数类。我一直将这归因于许多命名空间导致混淆的事实。

我建议你将类分解为逻辑名称空间，尽可能合理和实用。但是，如果每个命名空间最终只有一个或两个类，那么你可能会破碎太多，应该考虑巩固。

来源

2009-01-10 23:04:33

“一般认为不好的形式” - 由谁？这看起来很有争议，根本不是一般的。我从来没有听说过。 – 2009-01-10 23:23:57

它的东西FxCop总是抱怨 - 这几乎所有我必须支持我:) – 2009-01-10 23:40:46

虽然微软不是普遍性，尤其是在非常通用的命名空间领域;几乎所有的编程语言都不是微软的;另外，恕我直言，命名空间内类的数量不是应该证明其存在的理由，但其他原因是 – 2011-06-20 07:33:10

我不知道任何规则的项目数量，但这些规则往往是过度广义的垃圾无论如何。确保同一名称空间中的项目之间存在逻辑连接。如果命名空间变得太拥挤（不太可能，我希望），或者命名空间中的事物最好只是松散地关联起来，考虑将其分解为多个命名空间。

来源

2009-01-10 23:07:32

如果构建一个库或模块，通常最好只使用一个名称空间，因为名称空间的主要功能是避免名称冲突，并且您可以控制将名称分配给类和接口的名称。

来源

2009-01-10 23:15:15

我会争辩说，命名空间层次结构只应该考虑设计和模型/ API的层次结构。

如果一个命名空间包含大量无关的类，请重新考虑您的设计。

相反的是，安德鲁说，我会不担心含有一些类命名空间 - 虽然它当然是真的，当需要表达设计层次应该只有那样细致。另一方面，我发现命名空间只包含一个非常特殊的类，或者也许只是一小部分类型，其中一个编码任务，其他编码提供一个API（异常，枚举参数...）。例如，System.Text.RegularExpressions（在.NET中）。当然，略多于一个班级，但只是只是。

来源

2009-01-10 23:28:59

命名空间经验法则

回答

相关问题