在同一个文件中有多个类是一种不好的做法吗？

我以前只为一个文件上一堂课。例如car.cs具有car类。但是，当我编写更多类时，我想将它们添加到同一文件中。例如car.cs具有car和door类，等等。

我的问题对Java，C＃，PHP或任何其他编程语言都有好处。我应该在同一个文件中尝试不包含多个类吗？

我认为您应该尝试将代码保持为每个文件1类。

我建议这样做，因为以后再找您的课程会更容易。而且，它可以更好地与您的源代码管理系统一起使用（如果文件发生更改，则说明特定的类已更改）。

我唯一一次认为每个文件使用多个类是正确的，是在使用内部类时……但是内部类在另一个类中，因此可以保留在同一文件中。内部类角色与外部类密切相关，因此可以将它们放置在同一文件中。

在Java中，该文件的工作方式是每个文件一个公共类。可以将一组Java文件收集到一个包中。

但是，在Python中，文件是“模块”，通常具有许多密切相关的类。就像Java包一样，Python包是一个目录。

这使Python在类和包之间有额外的分组级别。

没有一个与语言无关的正确答案。它随语言而变化。

每个文件一个类是一个很好的规则，但是适当地进行一些例外是合适的。例如，如果我正在一个项目中，大多数类具有关联的集合类型，那么通常我会将类及其集合保存在同一文件中，例如：

public class Customer { /* whatever */ }

public class CustomerCollection : List<Customer> { /* whatever */ }

最好的经验法则是每个文件都保留一个类，除非这样会使事情变得更难而不是容易。由于Visual Studio的“在文件中查找”是如此有效，因此您可能不必花费大量时间来查找文件结构。

不，我不认为这是完全不好的做法。我的意思是，一般来说，每个类最好有一个单独的文件，但是绝对有一些例外情况，在这种情况下，最好在一个文件中有一堆类。一个很好的例子是一组Exception类，如果对于给定的组有几十个此类，为每个两个线性类单独创建一个单独的文件真的有意义吗？我不会。在这种情况下，在一个类别中具有一组例外会减少麻烦和简单的恕我直言。

我发现，每当我尝试将多种类型组合到一个文件中时，我总是会回头将它们分开并仅仅因为它们使它们更易于查找而已。每当我结合时，最终总会有片刻试图找出我定义的类型x的wtf。

因此，现在，我的个人规则是，每个单独的类型（子类可能除外，子类是指类内的类，而不是继承的类）都拥有自己的文件。

由于您的IDE为您提供了“导航到”功能，并且您可以对类中的命名空间进行一些控制，因此在同一个文件中包含多个类所带来的以下好处对我来说是非常值得的。

家长-子女班

在许多情况下，我发现在其基类文件中包含继承的类非常有帮助。

然后很容易查看子类继承哪些属性和方法，并且该文件提供了整体功能的快速概述。

公共：小型-助手-DTO类

当您需要几个普通类和小型类来实现特定功能时，我发现拥有一个包含所有引用的文件非常多余，并且只包含一个4-8 Liner类。

只需滚动一个文件而不是在10个文件之间切换，代码导航也变得更加容易。当您只需要编辑一个引用而不是10时，它也更易于重构。

总体上打破每个文件1类的Iron规则可以为组织代码提供更多的自由。

然后会发生什么，实际上取决于您的IDE，语言，团队沟通和组织技能。

但是，如果您想要那种自由，为什么要为铁腕统治而牺牲它？

如果您在团队中工作，则将类保存在单独的文件中会更容易控制源并减少冲突的可能性（多个开发人员同时更改同一文件）。我认为这也使查找所需的代码更加容易。

我一直遵循的规则是在同名文件中拥有一个主类。我可能会或可能不会在该文件中包括帮助程序类，这取决于它们与文件的主类的紧密程度。支持类是独立的，还是它们自己有用？例如，如果类中的方法需要特殊的比较来对某些对象进行排序，那么将比较函子类与使用它的方法捆绑到同一文件中就不会感到困扰。我不希望在其他地方使用它，而且单独使用它也没有意义。

从未来的发展和可维护性的角度来看，这可能是不好的。如果您有Car.cs类，则记住Car类的位置要容易得多。如果Widget.cs不存在，您将在哪里寻找Widget类？它是汽车部件吗？它是引擎小部件吗？哦，也许这是一个百吉饼小部件。

在只有我考虑的文件位置的时间，当我要创建新类。否则，我绝不会按文件结构导航。我使用“转到课堂”或“转到定义”。

我知道这有点像培训问题；从项目的物理文件结构中解放出来需要实践。不过，这是非常有益的；）

如果将它们放在同一文件中感觉很好，请成为我的客人。不能用Java中的公共类来做到这一点;）

根据经验，一个类/一个文件是必经之路。不过，我经常在一个文件中保留几个接口定义。一个文件中有几个类？只有当他们是非常密切的关系弄好了，并且非常小（<5种方法和成员）

正如编程中很多时间都是如此，它很大程度上取决于情况。

例如，所讨论的类的凝聚力是什么？他们紧密耦合吗？它们完全正交吗？它们在功能上相关吗？

Web框架提供通用的widgets.w包含BaseWidget，TextWidget，CharWidget等的任何文件都不会过时。

框架的用户不会在定义more_widgets文件以包含其从框架小部件派生用于其特定域空间的其他小部件时脱颖而出。

当这些类是正交的并且彼此无关时，将分组到单个文件中确实是人为的。假设有一个应用程序来管理制造汽车的机器人工厂。一个名为零件的文件，其中包含CarParts和RobotParts将是毫无意义的……在维修备件的订购与工厂生产的零件之间似乎没有太多的关系。这样的连接不会增加有关您正在设计的系统的信息或知识。

最好的经验法则是不要以经验法则来约束您的选择。建立经验法则是为了进行初切分析，或限制那些无法做出好的选择的人的选择。我认为大多数程序员都希望相信他们能够做出正确的决定。

除非有充分的理由，否则您应该避免这样做。

一个具有几个小相关类别的文件比几个文件更具可读性。例如，当使用“案例类”来模拟联合类型时，每个类之间都有很强的关系。对多个类使用相同的文件的优点在于，对于读者而言，将它们可视地分组在一起。

在您的情况下，汽车和门似乎根本不相关，并且在car.cs文件中找到门类将是意外的，因此不要如此。

每个文件一个类更易于维护，并且对于其他查看您代码的人来说也更加清晰。它也是强制性的，或者在某些语言中非常受限制。

例如，在Java中，您不能为每个文件创建多个顶级类，它们必须位于单独的文件中，其中类名和文件名相同。

Smalltalk的答案是：您不应该有文件（用于编程）。它们使版本控制和导航痛苦。