单个.cs文件中有多个类-是好是坏？[关闭]

建议在.cs文件中创建多个类，还是每个.cs文件都应有一个单独的类？

例如：

public class Items
{
    public class Animal
    {
    }

    public class Person
    {
    }

    public class Object
    {
    }
}

一分钟就躲避一个事实，那就是这不是一个好的架构示例，.cs文件中是否有多个类才有代码味道？

在我看来，您所举的例子确实很好。您在声明内部类，因此将它们保留在同一文件中是非常明智的。解决此问题的唯一方法是使您的Items类成为部分类并将其拆分为多个文件。我认为这是不好的做法。对于嵌套类，我的一般政策是它们应较小且私有。有两个例外：

• 您正在设计类集群（在Objective-c中更常见），因此使用部分类方法可能是明智的
• 您需要一个仅与父类的公共API一起使用的枚举。在这种情况下，我更喜欢在父类中声明一个公共枚举，而不是污染我的名称空间。枚举是“内部枚举”，有效地赋予了它明确的范围。

如果您对问题的措词有所不同，并询问“我是否应该将每个命名空间级别的类放入其自己的文件中”，那么我的答案将是“是”。

在设计课程时，我们尊重“单一责任原则”。如果代码的形状遵循其语义，则读取代码变得容易得多，因此按类拆分文件是明智的。

从机械角度来看，每个类都有一个文件具有多个优点。您可以在不同的窗口中同时打开多个类。这一点特别重要，因为没有认真的开发人员使用少于两个屏幕。能够有更多的语境中前我的头意味着我能保持更多的情况下在我的头上。（大多数IDE都可以让您打开同一文件两次，但是我觉得很尴尬）。

下一个重要方面是源代码控制和合并。通过将您的类分开，可以避免对同一文件进行更改时的麻烦，因为需要更改单独的类。

老实说，请不要在文件中添加多个根类。在我的上一份工作中，文件不仅具有多个类，而且具有多个名称空间，并且这些文件扩展到成千上万行代码中。 非常困难的尝试效仿。

如果存在密切相关的类，则可以类似地命名其文件或将其放在子文件夹中。

类文件的物理分离有助于（注意，不是全部结束）引起关注点分离和更松散的耦合。

另一方面，您的示例未显示多个根类。有几个嵌套类（请注意：请尽量不要使嵌套类任何东西，但是private如果可以设计的话），并且在一个文件中包含它是完全可以的。

如果文件具有很高的内聚性，例如，它是替代几个非常短的，命名相似的文件的替代方法，那么这是个好主意。

举例来说，我发现使用功能NHibernate当它是如果我继续更容易Entity，并EntityMap在一个文件中，尽管我什么工具可能不得不说一下。

在大多数情况下，这只会使类很难找到。谨慎使用并谨慎使用。

简单地说，是的，这样做不好，我会告诉你为什么，稍后，当您的解决方案变大时，您会忘记类所在的位置，因为文件名将不再代表内容是什么，文件名是什么AnimalPersonObject.cs就是不可行的。

当然可以通过使用诸如reshaper之类的工具中的功能跳转到类型来解决此问题，但是每个文件（包括接口）一个类实际上是我见过的任何代码标准的骨干，不仅在.net中，而且在Java和C ++和许多其他语言，那些通常不存在维护问题的语言，您会发现初级开发人员发现很难掌握代码。

几乎所有的代码优化工具都会告诉您将类移动到单独的文件中，所以对我来说，这是代码的味道，需要驱逐它才能消除:)

另一个问题是在同一个文件中包含非常大且相似的类-当您始终无法看到类声明时-您可能最终将断点放在错误的类中并想知道为什么它们没有被击中... rr！:)

基本上，如果只需要在“父”类中使用该类（就范围而言），则通常将其定义为嵌套类是合适的。