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

60

我认为你应该尽量让你的代码每个文件1个类。

我建议这样做，因为稍后会更容易找到你的课程。此外，它可以更好地处理源代码管理系统（如果文件发生更改，那么您知道某个类已更改）。

我认为对每个文件使用多个类的唯一时间是使用内部类时......但内部类在另一个类内，因此可以留在同一个文件中。内部类的角色与外部类紧密相关，所以将它们放在同一个文件中是很好的。

来源

2008-12-11 19:54:03

8

我发现，每当我尝试将多个类型合并为一个文件时，我总是会回头并将它们分开，因为它使它们更容易找到。每当我结合起来，总会有一个时刻，我试图找出wtf我定义的类型x。

所以，现在我的个人规则是，每个单独的类型（除了子类，也就是说类中的类，而不是继承类）都有自己的文件。

来源

2008-12-11 19:54:06

4

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

来源

2008-12-11 19:55:09

+1

正如在http://stackoverflow.com/questions/360643/is-it-a-bad-practice-to-have-multiple-classes-in-the-same-file/360675#360675中提到的，与常见导航工具，你不必依靠文件导航。您可以通过类/成员进行导航。 – Suma 2011-04-05 15:25:24

6

如果您正在团队中工作，将类保存在单独的文件中可以更轻松地控制源并减少冲突的可能性（多个开发人员同时更改同一文件）。我认为它更容易找到你正在寻找的代码。

来源

2008-12-11 19:55:39

5

只有时间我认为文件位置是当我必须创建新的类。否则我从来没有导航文件结构。我使用“上课”或“去定义”。

我知道这是一个培训问题;摆脱项目的物理文件结构需要练习。这是非常有益的，但;）

如果感觉很好，把他们在同一个文件中，成为我的客人。不能用java中的公共类来实现;）

来源

2008-12-11 19:58:36 krosenvold

3

作为一个经验法则，一个类/一个文件是要走的路。不过，我经常将几个接口定义保存在一个文件中。一个文件中有几个类？只有当他们都非常莫名其妙密切相关的，和非常小的（< 5方法和成员），每个文件

来源

2008-12-11 19:58:51 Treb

1

一类是易于维护和其他人在看你的代码更加清晰。这也是强制性的，或者在某些语言中非常受限制。

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

来源

2008-12-11 19:59:47 Robin

22

在Java中，一个公开每个文件的类是语言的工作方式。一组Java文件可以被收集到一个包中。

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

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

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

来源

2008-12-11 20:03:07

5

我总是经历的规则是在一个具有相同名称的文件中有一个主类。我可能会也可能不会在该文件中包含帮助程序类，具体取决于它们与文件主类的耦合程度。支持类是独立的，还是它们自己有用？例如，如果某个类中的某个方法需要对某些对象进行排序的特殊比较，那么它就不会打扰我将比较函子类与使用它的方法捆绑到相同的文件中。我不希望在其他地方使用它，它是独立的没有意义。

来源

2008-12-11 20:06:34 Boojum

15

每个文件一个类是一个很好的规则，但适合做一些例外。举例来说，如果我在大多数类有关联集合类型的一个项目我工作，我常常会保持类和它在同一个文件集合，例如：

public class Customer { /* whatever */ } 

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

拇指最好的规则是每个文件保留一个类，除非开始让事情变得更难而不是更容易。由于Visual Studio的“在文件中查找”功能非常有效，因此您可能无需花费太多时间浏览文件结构。

来源

2008-12-11 20:14:48

+2

不，这是个不好的建议。听取接受答案的建议。你应该从保存的类中分离对象库。它只会造成不必要的混乱。 – Hudson 2015-09-09 06:46:49

2

在程序设计中这么多时候都是如此，这很大程度上取决于情况。

例如，有问题的类的凝聚力是什么？它们是紧密结合的吗？它们是完全正交的吗？他们在功能上有关系吗？

它不会是脱节的web框架供应widgets.whatever含有BaseWidget，TextWidget，CharWidget文件的通用等

框架的用户不会是脱节的定义一个more_widgets文件，用于包含它们从其特定域空间的框架小部件派生出来的其他小部件。

当这些类是正交的，并且与彼此无关时，将其分组为单个文件确实是人为的。假设一个应用程序来管理构建汽车的机器人工厂。一个名为包含CarParts和RobotParts的零件的文件将毫无意义......维护的备件订购和工厂制造的零件之间不太可能存在很大关系。这样的加入不会增加关于您正在设计的系统的信息或知识。

也许最好的经验法则是不要用经验法则来约束你的选择。经验法则用于第一次分析，或限制那些不能做出正确选择的人的选择。我想大多数程序员都希望相信他们有能力做出正确的决定。

来源

2008-12-11 20:19:28

14

不，我不认为这是一个完全不好的做法。我的意思是通常最好每个类都有一个单独的文件，但肯定有很好的异常情况，最好在一个文件中有一堆类。一个很好的例子就是一组Exception类，如果你对某个给定的组有一个这样的几个这样的类，那么为每个两个班轮类使用一个单独的文件是否真的有意义？我不会争辩。在这种情况下，在一个类中有一组例外是非常麻烦和简单的恕我直言。

来源

2010-01-11 19:02:28 James

1

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

来源

2010-01-11 19:12:15

2

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

一个文件与几个小相关类可以比几个文件更具可读性。例如，当使用'case class'时，为了模拟union类型，每个class之间都有很强的关系。对多个类使用相同的文件具有将它们以可视方式分组在一起的优点。

在你的情况，有车有门似乎并不在所有相关的，并找到在car.cs文件大门类将是意想不到的，所以不要。

来源

2012-02-22 16:21:58

2

由于您IDE为您提供“导航到”功能，你必须在一些控制命名空间的类中然后在同一文件中有多个类的下方好处是相当值得的我。

父 - 子类

在许多情况下，我觉得很有帮助的继承其基地类文件中类。

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

市民：小 - 助手 - DTO类

当你需要几个平原和小类为特定功能我觉得很冗余与所有的引用文件，包括只是一个4-8班轮类.....

代码导航也更容易滚动o NE文件，而不是交换文件10之间...它也更容易重构时，你必须编辑只是一个参考，而不是10 .....

总体每个文件突破1级的铁律提供一些额外的自由来组织你的代码。

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

但是，如果你想要那种自由，为什么要牺牲它的铁律呢？

来源

2016-11-16 15:28:18

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

回答

相关问题