Pok*_*kus 62 language-agnostic oop class file
我曾经有一个类用于一个文件.例如,car.cs有类汽车.但是当我编写更多类时,我想将它们添加到同一个文件中.例如car.cs具有类车和门类等.
我的问题适用于Java,C#,PHP或任何其他编程语言.我应该尝试在同一个文件中没有多个类,还是可以的？
Pat*_*ins 76
我认为你应该尝试将你的代码保持为每个文件1个类.
我建议这样做,因为以后更容易找到你的课程.此外,它将更好地与您的源控制系统(如果文件更改,然后您知道某个特定的类已更改).
我认为每个文件使用多个类是正确的唯一一次是当你使用内部类时......但是内部类在另一个类中,因此可以保留在同一个文件中.内部类角色与外部类强烈相关,因此将它们放在同一个文件中就可以了.
S.L*_*ott 26
在Java中,每个文件一个公共类就是语言的工作方式.可以将一组Java文件收集到包中.
然而,在Python中,文件是"模块",并且通常具有许多密切相关的类.Python包是一个目录,就像Java包一样.
这为Python提供了类和包之间的额外级别的分组.
没有一个与语言无关的正确答案.它因语言而异.
Rya*_*ndy 18
每个文件一个类是一个很好的规则,但是做一些例外是合适的.例如,如果我在一个大多数类都有关联集合类型的项目中工作,通常我会将类及其集合保存在同一个文件中,例如:
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
最好的经验法则是每个文件保留一个类,除非它开始变得更难而不是更容易.由于Visual Studio的"在文件中查找"非常有效,因此您可能无需花费太多时间查看文件结构.
Jam*_*mes 13
不,我不认为这是一个完全不好的做法.我的意思是,一般来说每个类最好有一个单独的文件,但是肯定有很好的异常情况,最好在一个文件中包含一堆类.一个很好的例子就是一组Exception类,如果你对一个给定的组有几十个这样的,那么为每个两个线性类分别单独一个文件真的有意义吗？我不会争辩.在这种情况下,在一个类中具有一组异常是不那么麻烦和简单的恕我直言.
我发现每当我尝试将多个类型组合到一个文件中时,我总是会回过头来将它们分开,因为它使它们更容易找到.每当我结合起来时,总会有一个时刻,我试图找出wtf我定义的类型x.
所以现在,我的个人规则是每个单独的类型(除了子类,通过它来表示类中的类,而不是继承的类)获取自己的文件.
由于您的IDE 为您提供了“导航到”功能，并且您可以对类中的命名空间进行一些控制，因此在同一文件中拥有多个类的以下好处对我来说非常值得。
父子类
在许多情况下，我发现在其基类文件中包含继承类非常有帮助。
然后很容易查看您的子类继承了哪些属性和方法，并且该文件提供了对整体功能的更快概述。
公共：小 - 助手 - DTO 类
当您需要多个普通和小型类来实现特定功能时，我发现拥有一个包含所有引用的文件并仅包含一个4-8 Liner类是非常多余的.....
代码导航也更容易，只需滚动一个文件而不是在 10 个文件之间切换......当你只需要编辑一个引用而不是 10 个时，它也更容易重构......
总体而言，打破每个文件 1 个类的Iron 规则为组织代码提供了一些额外的自由。
然后会发生什么，实际上取决于您的 IDE、语言、团队沟通和组织技能。
但如果你想要那种自由，为什么要为了铁的规则而牺牲它呢？
从未来的发展和可维护性的角度来看,这可能是坏事.如果你有一个Car.cs类,那么记住Car类的位置要容易得多.如果Widget.cs不存在,你会在哪里寻找Widget类？这是一个汽车小工具吗？它是一个引擎小部件吗？哦,也许这是一个百吉饼小部件.
我经常使用的规则是在一个具有相同名称的文件中有一个主类.我可能会也可能不会在该文件中包含辅助类,具体取决于它们与文件主类的耦合程度.支持类是独立的,还是它们自己有用？例如,如果类中的方法需要进行特殊比较以对某些对象进行排序,那么将比较仿函数类捆绑到与使用它的方法相同的文件中并不困扰我.我不希望在其他地方使用它,它本身就没有意义.
我考虑文件位置的唯一时间是我必须创建新类.否则我永远不会按文件结构导航.我用"去上课"或"去定义".
我知道这有点像培训问题; 从项目的物理文件结构中解放出来需要练习.这是非常有益的;)
如果将它们放在同一个文件中感觉很好,请成为我的客人.不能用java中的公共类做到这一点;)