命名空间中的类数-代码气味？

我有一个C＃库，该库由多个可执行文件使用。库中只有几个命名空间，我只是注意到其中一个命名空间中包含许多类。由于分类，我总是避免在单个名称空间中包含太多的类，并且因为在潜意识里，我认为具有更深层次的名称空间层次结构看起来“更漂亮”。

我的问题是：当一个命名空间具有许多类时，即使这些类彼此相关，是否有人将其视为“代码气味”？您是否会花大力气在允许子分类的类中找到细微差别？

不必要。如果所有类确实属于名称空间定义的类别，那么就可以了。

您可以做的是查看这些类并思考合并其中一些类的可能性。这些类中的一小部分很可能支持“家庭”功能，但由于某些历史原因而单独实施。现在，当经过了足够的时间后，可能会有更好的构图。

您应该避免有太多的命名空间，因为这会使库更难于使用和导航给程序员。而且，对于许多名称空间，设计者要为每个名称空间提供准确的名称，并决定特定类应属于哪个名称空间，可能成为挑战。

最简单的方法是将所有主要类都放在一个名称空间中，将所有高级方案类都放入子名称空间中。.NET Framework一直在执行此操作，请参见System.Collections和System.Collections.Specialized以获得该实践的良好示例。

仅使用一个或两个第一级名称空间，您的代码将变得更容易导航，隐藏高级或专用类，直到程序员准备发现它们为止。

只要它们属于彼此并相互关联，在命名空间中有太多的类就没有问题。

一个类是否属于它自己的单独命名空间是个人喜好的问题。

什么看起来更自然？

Parsers.XML.XmlParser.cs
Parsers.XmlParser.cs

这完全取决于您希望如何查看和调用代码。

就个人而言，仅当我知道将有一个以上的类属于我时，我才喜欢使用单独的名称空间。

这可以。拥有名称空间的主要原因是为了避免名称冲突，只有在此之后，我们才应该考虑逻辑范围，这更是个人选择而非规则的问题。当然，欢迎一些明智的规则。没有人希望在一个命名空间中滚动浏览3k〜4k类。

一个很好的例子是C ++标准库中的std名称空间，它使您可以将自己的算法与标准算法分开。