命名空间经验法则

Question

在将项目进一步分类到新名称空间之前，是否有一些关于在给定名称空间中应该有多少类，接口等的一般经验法则？喜欢最佳实践或社区偏好？或者这是个人偏好吗？

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

Answer 1

在任何可靠的来源我都没有看到任何经验法则，但在与大多数开发人员合作时，我有一些常见的偏好。有一些东西可以帮助您创建名称空间。

1. 班级的领域
2. 它是一个类还是一个接口（我看到一些开发人员喜欢像ShopApp.Model.Interfaces这样的名称空间）。如果您的接口是某些服务或数据合同，则工作得非常好。
3. 没有太深的名称空间，3（。）就足够了。不止这些可能会让人讨厌。
4. 如果在任何时候您觉得它变得不合逻辑或难以管理，请打开以重新组织命名空间。
5. 不要仅仅为了它而创建名称空间。

快乐编码!!!

Answer 2

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

Answer 3

我不知道任何项目数量的经验法则，但这些规则往往是过度概括的垃圾。确保同一名称空间中的项之间存在逻辑连接。如果名称空间过于拥挤（我希望不太可能），或者命名空间中的内容最多只是松散相关，请考虑将其分解为多个名称空间。

Answer 4

我认为命名空间层次结构应该只考虑设计和模型/ API的层次结构。

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

与Andrew所说的相反，我不担心包含少数类的命名空间 - 尽管当然，层次结构应该只是表达设计所需的细粒度。

另一方面，我发现命名空间只包含一个非常特殊的类，或者只是一小组类型，其中一个编码任务，其他类型提供API（例外，枚举）是完全合理的。争论......）。

举个例子，取System.Text.RegularExpressions（在.NET中）。当然，略多于一个班级，但仅仅是。

Answer 5

在命名空间中包含少量类通常被认为是不好的形式。我一直将此归结为许多命名空间导致混淆的事实。

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