6

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

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
4

5 回答 5

4

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

  1. 类域
  2. 它是一个类还是一个接口（我看到一些开发人员更喜欢 ShopApp.Model.Interfaces 之类的命名空间）。如果您的接口是某种服务或数据合同，则效果非常好。
  3. 不要有太深的命名空间，3 (.) 就足够了。不仅如此，可能会令人讨厌。
  4. 如果您在任何时候觉得它变得不合逻辑或难以管理，请愿意重新组织命名空间。
  5. 不要仅仅为了它而创建名称空间。
于 2009-01-10T23:21:08.840 回答
3

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

于 2009-01-10T23:15:15.433 回答
2

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

于 2009-01-10T23:07:32.330 回答
1

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

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

与 Andrew 所说的相反，我不会担心名称空间包含很少的类——当然，层次结构应该只根据需要细粒度来表达设计。

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

System.Text.RegularExpressions以（在 .NET 中）为例。当然，略多于一堂课，但仅此而已。

于 2009-01-10T23:28:59.307 回答
0

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

我建议您将类分解为尽可能合理和实用的逻辑名称空间。但是，如果您最终每个命名空间只有一两个类，那么您可能会分崩离析，应该考虑整合。

于 2009-01-10T23:04:33.240 回答