程序员应该在一个文件中放入多少个类？

本文介绍了程序员应该在一个文件中放入多少个类？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

在面向对象的语言中，你需要遵循什么准则将类分组到一个文件中？你总是给每个类一个单独的文件吗？你把紧耦合的课堂放在一起吗？你有没有在一个文件中指定一个接口的几个实现？你是根据实现可能有多少行代码，或者如何混乱它可能看起来类的用户吗？

In your object-oriented language, what guidelines do you follow for grouping classes into a single file? Do you always give each class a seperate file? Do you put tightly coupled classes together? Have you ever specified a couple of implementations of an interface in one file? Do you do it based on how many lines of code the implementation might be or how "cluttered" it might look to the user of the class? Or would the user prefer to have everything on one place?

推荐答案

就个人而言，我建议每个档案一个类别 / em>辅助类对文件中的主类是私有的。例如，C＃中的嵌套类将保留在父类文件中，但是在其他地方，可能有用的实用程序类会被分成自己的文件或甚至命名空间。

Personally, I suggest one class per file unless the secondary classes are private to the primary class in the file. For example, a nested class in C# would remain in the parent classes file, but utility classes that might be useful elsewhere get broken into their own file or even namespace.

关键是了解你的环境和人们会在哪里寻找东西。如果有一个确定的方法，在你烦恼之前仔细考虑。如果你的同事期望相关的，紧密绑定的类将在一个单一的文档，不得不搜索他们可能会讨厌（虽然现代IDEs它不应该是一个问题）。

The key is to understand your environment and where people will look for things. If there is an established methodology in place, think carefully before you upset it. If your coworkers expect that related, tightly bound classes will be in a single document, having to search for them could be annoying (although with modern IDEs it shouldn't be a problem).

将事物分成更多文件而不是更少的另一个原因是版本控制。如果你做一个小的改变，它应该只改变一个小文件尽可能。如果你做一个彻底的更改，它是显而易见的查看日志，因为所有的文件（和间接，类）受影响的注释。

An additional reason for breaking things into more files rather than less is version control. If you make a small change, it should change only a small file where possible. If you make a sweeping change, it is obvious looking at the logs because of all the files (and indirectly, classes) that were affected are noted.