每个命名空间分支的理想类数

本文关键字：理想 分支 命名空间 | 更新日期: 2023-09-27 17:47:21

您认为每个命名空间"分支"理想的类数量是多少？在什么时候会决定将一个命名空间分解为多个命名空间？我们暂且不讨论类的逻辑分组（假设它们在逻辑上分组正确），在这一点上，我专注于可维护与不可维护的类数。

每个命名空间分支的理想类数

"42？不，这不行..."

好吧，让我们发挥我们的编程能力，看看Microsoft的意见是什么：

# IronPython
import System
exported_types = [
  (t.Namespace, t.Name)
  for t in System.Int32().GetType().Assembly.GetExportedTypes()]
import itertools
get_ns = lambda (ns, typename): ns
sorted_exported_types = sorted(exported_types, key=get_ns)
counts_per_ns = dict(
  (ns, len(list(typenames)))
  for ns, typenames
  in itertools.groupby(sorted_exported_types, get_ns))
counts = sorted(counts_per_ns.values())
print 'Min:', counts[0]
print 'Max:', counts[-1]
print 'Avg:', sum(counts) / len(counts)
print 'Med:',
if len(counts) % 2:
  print counts[len(counts) / 2]
else: # ignoring len == 1 case
  print (counts[len(counts) / 2 - 1] + counts[len(counts) / 2]) / 2

这为我们提供了有关每个命名空间的类型数量的以下统计信息：

C:'tools'nspop>ipy nspop.py
Min: 1
Max: 173
Avg: 27
Med: 15

使用现代 IDE 和其他开发工具，我会说，如果所有类都属于一个命名空间，那么为了可维护性，就没有任意数量的类应该分解命名空间。

我认为命名空间应该尽可能大。如果有创建同级命名空间或子命名空间的逻辑原因，请这样做。 在我看来，拆分为命名空间的主要原因是简化开发，使开发人员更容易浏览命名空间层次结构以找到他们需要的内容。

如果有一个包含大量类型的命名空间，并且您觉得很难找到某些类型，请考虑将它们移动到另一个命名空间。如果类型专用于父命名空间类型，我将使用子命名空间，如果这些类型可以在没有原始命名空间类型的情况下使用或具有不同的用途，我将使用同级命名空间。 当然，这完全取决于您正在创建的内容和目标受众。

如果命名空间的类型少于 20 个，则不太可能值得拆分。但是，您应该在设计期间考虑命名空间分配，以便在开发时预先知道哪些类型在哪些命名空间中。如果在开发过程中进行命名空间分配，则在确定哪些内容应放在何处时，需要进行大量重构。

这里没有涉及的一件事，尽管它在某种程度上与 Chris 的观点有关，那就是命名空间的可学习性不仅与项目的数量有关。

（顺便说一下，这适用于最广泛意义上的"命名空间" - 类本身是一般意义上的命名空间，因为它包含某些名称，这些名称在该上下文中的含义与在另一个上下文中的含义不同，枚举也是这种意义上的命名空间）。

假设我遇到一个带有 Element 类的 XML 相关命名空间。我对此有所了解，当我查看 Attribute 类时，我看到了一些相似之处。当我看到一个 ProcessingInstruction 类时，我可以对它的工作原理做出合理的猜测（如果我猜错了，这可能是一个设计缺陷，充其量差异不仅需要记录，而且需要解释）。在我看到它之前，我可以猜到有一个评论类。我会去寻找你的 TextNode 类，想知道这些是否都继承自 Node，而不必从文档中了解它们。我会想知道你在 Lang 课程中采取了几种合理的方法中的哪一种，而不是想知道它是否存在。

因为这一切都与我已经知道的领域有关，所以这七个类的概念"成本"比这七个类要低得多，比如绵羊、电视、西贡秋天、Enuii、AmandaPalmersSoloWork、ForArtsSakeQuotient 和 DueProcess。

这与Chirs的观点有关，因为他说，为了可用性，建议我们减少选择的数量。但是，如果我们按字母顺序选择国家/地区，我们会立即浏览整个列表并立即选择我们需要的国家/地区，因此减少选择的建议不适用（事实上，一次几个选项可能既不那么有用又可能具有侮辱性）。

如果你的命名空间有 200 个名字，但你只需要真正学习六个名字就可以理解很多，那么它比拥有十几个彼此关系不大的名字要容易得多。

我知道您不想讨论逻辑分组，但是要进行拆分，您需要能够对两个不同的命名空间进行分组。我会开始考虑大约 30 个类的新命名空间;但是我不认为这是一个主要问题。

我必须说，我发现以上所有内容都非常令人惊讶。

可用性专家告诉我们，将菜单中的选项数量保持在有限的数量，以便我们可以立即看到所有选择。这同样适用于您如何组织工作。

我通常期望命名空间中有 4-10 种类型。节省了这么多的狩猎回合的东西和上下滚动。 使用锐化器移动东西是如此快速和容易，以至于我看不出有任何理由不这样做。

应该提到的另一件事是，将包含扩展方法的类放在其自己的命名空间中通常是值得的，以便您可以使用 using 指令启用或禁用这些扩展方法。因此，如果命名空间中的东西是包含扩展方法的静态类，则答案是 1。

相关文章：