我曾经为一个文件创建了一个类。例如， car.cs 具有类 car 。但是当我编写更多类时，我想将它们添加到同一个文件中。例如 car.cs 有 car 类和门类等。
我的问题适用于Java，C＃，PHP或任何其他编程语言。我应该尝试在同一个文件中没有多个类，还是可以吗？
答案 0 :(得分：74)
我认为您应该尝试将每个文件的代码保留为1个类。
我建议这样做，因为以后更容易找到你的课程。此外，它将更好地与您的源控制系统（如果文件更改，然后您知道某个特定的类已更改）。
我认为每个文件使用多个类是正确的唯一一次是当你使用内部类时...但是内部类在另一个类中，因此可以保留在同一个文件中。内部类角色与外部类强烈相关，因此将它们放在同一个文件中就可以了。
答案 1 :(得分：24)
在Java中，每个文件一个 public 类是语言的工作方式。可以将一组Java文件收集到包中。
然而，在Python中，文件是“模块”，并且通常具有许多密切相关的类。 Python包是一个目录，就像Java包一样。
这为Python提供了在类和包之间进行额外级别的分组。
没有一个与语言无关的正确答案。它因语言而异。
答案 2 :(得分：18)
每个文件一个类是一个很好的规则，但是做一些例外是合适的。例如，如果我在大多数类都有关联集合类型的项目中工作，通常我会将类及其集合保存在同一个文件中，例如：
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
最好的经验法则是每个文件保留一个类，除非它开始使事情变得更难而不是更容易。由于Visual Studio的“在文件中查找”非常有效，因此您可能不必花费太多时间来查看文件结构。
答案 3 :(得分：13)
不，我认为这不是一个完全不好的做法。我的意思是，一般来说每个类最好有一个单独的文件，但是肯定有很好的异常情况，最好在一个文件中包含一堆类。一个很好的例子就是一组Exception类，如果你对一个给定的组有几十个这样的，那么为每个两个线性类分别单独一个文件真的有意义吗？我不会争辩。在这种情况下，在一个类中有一组例外是不那么麻烦和简单的恕我直言。
答案 4 :(得分：9)
我发现每当我尝试将多个类型组合到一个文件中时，我总是会回过头来将它们分开，因为它使它们更容易找到。每当我结合起来时，总会有一个时刻，我试图找出wtf我定义的类型x。
所以现在，我的个人规则是每个单独的类型（除了子类，通过它来表示类中的类，而不是继承的类）获取自己的文件。
答案 5 :(得分：7)
如果您正在组建团队，则将类保留在单独的文件中可以更轻松地控制源并减少冲突的可能性（多个开发人员同时更改同一文件）。我认为这样可以更容易地找到您正在寻找的代码。
答案 6 :(得分：6)
从未来的发展和可维护性的角度来看可能会很糟糕。如果你有一个Car.cs类，那么记住Car类的位置要容易得多。如果Widget.cs不存在，你会在哪里寻找Widget类？这是一个汽车小工具吗？它是一个引擎小部件吗？哦，也许这是一个百吉饼小部件。
答案 7 :(得分：6)
我经常使用的规则是在一个具有相同名称的文件中有一个 main 类。我可能会也可能不会在该文件中包含辅助类，具体取决于它们与文件主类的耦合程度。支持类是独立的，还是它们自己有用？例如，如果类中的方法需要进行特殊比较以对某些对象进行排序，那么将比较仿函数类捆绑到与使用它的方法相同的文件中并不困扰我。我不希望在其他地方使用它，它本身就没有意义。
答案 8 :(得分：5)
我认为文件位置的唯一时间是我必须创建新类的时间。否则我从不按文件结构导航。我用“去上课”或“去定义”。
我知道这有点像培训问题;从项目的物理文件结构中解放出来需要练习。但这非常有益;）
如果将它们放在同一个文件中感觉很好，请成为我的客人。不能用java中的公共类做到这一点;）
答案 9 :(得分：3)
由于 IDE 为您提供＆＃34; 导航到＆＃34;功能，你可以控制你的类中的命名空间，然后在同一个文件中拥有多个类的下面好处对我来说是非常值得的。
父级 - 子级
在许多情况下，我发现在 Base 类文件中包含继承类非常有用。
您可以很容易地看到子类继承的属性和方法，并且该文件可以更快地概述整体功能。
公开：小 - 助手 - DTO课程
如果特定功能需要多个普通和小类，我发现拥有包含所有引用的文件非常多余包括只有 4-8班轮类......
代码导航也可以更轻松地滚动浏览一个文件，而不是在10个文件之间切换...当您只需编辑一个参考时，它也更容易重构 10 ....
整体打破每个文件1类的铁规则提供了一些额外的自由来整理代码。
然后会发生什么，实际上取决于您的IDE，语言，团队沟通和组织技能。
但是，如果你想要那种自由，为什么要为了铁律而牺牲呢？
答案 10 :(得分：2)
根据经验，一个类/一个文件是可行的方法。不过，我经常在一个文件中保留几个接口定义。一个文件中的几个类？只有当他们非常以某种方式密切相关时，并且非常小（＆lt; 5方法和成员）
答案 11 :(得分：2)
编程中的大部分时间都是如此，这在很大程度上取决于具体情况。
例如，有问题的课程的凝聚力是什么？它们紧密耦合吗？它们完全正交吗？它们的功能是否相关？
对于提供通用小部件的Web框架来说，它不会脱节。任何包含BaseWidget，TextWidget，CharWidget等的文件。
框架的用户在定义more_widgets文件时不会脱节，以包含他们从特定域空间的框架小部件派生的其他小部件。
当类是正交的，并且彼此无关时，分组到单个文件中确实是人为的。假设一个应用程序来管理构建汽车的机器人工厂。一个名为包含CarParts和RobotParts的零件的文件将毫无意义......维护备件的订购与工厂生产的零件之间不太可能存在太大关系。这样的连接不会增加关于您正在设计的系统的信息或知识。
也许最好的经验法则是不要通过经验法则限制你的选择。为第一次分析创建经验法则，或限制那些无法做出正确选择的人的选择。我认为大多数程序员都希望他们能够做出正确的决定。
答案 12 :(得分：2)
除非你有充分的理由，否则你应该避免这样做。
一个包含多个小相关类的文件比几个文件更具可读性。 例如，在使用“案例类”时，为了模拟联合类型，每个类之间存在很强的关系。 对多个类使用相同的文件有一个优点，就是可以为读者直观地将它们组合在一起。
在你的情况下，汽车和车门似乎根本没有相关性，并且在car.cs文件中找到门类是意料之外的，所以不要。
答案 13 :(得分：1)
每个文件一个类的维护更简单，对于查看代码的任何人来说都更加清晰。它也是强制性的，或者在某些语言中非常有限。
例如，在Java中，您无法为每个文件创建多个顶级类，它们必须位于类名和文件名相同的单独文件中。
答案 14 :(得分：1)
Smalltalk答案是：你不应该有文件（用于编程）。它们使版本控制和导航变得痛苦。