您认为每个命名空间“分支”应该有多少个类最理想?在什么时候应该决定将一个命名空间拆分成多个?我们不讨论类的逻辑分组(假设它们已经按逻辑正确分组),此时我关注的是可维护性与不可维护性之间的类数量。
您认为每个命名空间“分支”应该有多少个类最理想?在什么时候应该决定将一个命名空间拆分成多个?我们不讨论类的逻辑分组(假设它们已经按逻辑正确分组),此时我关注的是可维护性与不可维护性之间的类数量。
"42?不,它行不通..."
好的,让我们发挥编程技巧,看看微软的意见:
# 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和其他开发工具,如果所有的类都属于一个命名空间,那么为了可维护性,就没有任意的数字来拆分命名空间。
这里没有涉及到的一件事,虽然它在某种程度上与Chris的观点有关,那就是命名空间的可学习性不仅仅与项目数量有关。
(顺便说一下,在最广泛的意义上,“命名空间”也适用于类本身,因为它包含了某些在该上下文中意味着与其他上下文中不同的名称,枚举类型在这个意义上也是一个命名空间)。
假设我遇到了一个与XML相关的命名空间,其中有一个Element类。我会了解一些关于它的信息,当我看到Attribute类时,我会发现一些相似之处。当我看到ProcessingInstruction类时,我可以猜测它的工作原理(如果我完全猜错了,那么这可能是一个设计缺陷,至少需要记录差异,而且需要解释)。我可以猜测在我看到它之前有一个Comment类。我会寻找你的TextNode类,并想知道它们是否都继承自Node,而不是从文档中了解它们。我会想知道你在Lang类中采取了几种合理的方法,而不是想知道它是否存在。
因为这些七个类都与我已经了解的领域相关,所以这七个类的概念“成本”要比如果这七个类被称为Sheep、Television、FallOfSaigon、Enuii、AmandaPalmersSoloWork、ForArtsSakeQuotient和DueProcess要低得多。
这与Chris的观点有关,因为他说我们建议为了可用性而保持选择数量较少。然而,如果我们有一个按字母顺序排列的国家选择,我们立即理解整个列表并立即选择我们需要的那个,因此保持选择数量不适用(实际上,一次只有几个选项可能既不太有用,也可能会冒犯)。
如果您的命名空间有200个名称,但您只需要真正学习其中的半打就能理解全部内容,那么它将比具有十几个名称且彼此之间关系很小的名称要容易理解得多。
我知道你不想讨论逻辑分组,但是要进行拆分,你需要能够对两个不同的命名空间进行分组。我建议在大约30个类左右考虑一个新的命名空间;但我不认为这是一个主要问题。
我必须说,我对以上所有内容都感到非常惊讶。
可用性专家告诉我们,在菜单中保持选择数量有限,以便我们可以立即看到所有选择。同样的原则也适用于如何组织您的工作。
在命名空间中,我通常期望有4-10种类型。这样可以节省大量查找和上下滚动的时间。使用resharper轻松移动东西,所以我不认为有任何理由不这样做。
using
指令启用或禁用这些扩展方法。因此,如果命名空间中的内容是包含扩展方法的静态类,则答案为1。