我正在查看我的一些项目，并将它们与我在github上看到的事物进行比较，我觉得我过度思考。我喜欢OOP，但我觉得我制作的文件太多，课程太多了。
例如，在一个小型项目中，我有一个跳棋游戏，我有很多文件，可能都进入一个文件/类。我如何知道何时过度考虑我的解决方案？这是我的一些文件的样子;
|src
| |- player.cpp
| |- piece.cpp
| |- color.cpp
| |- ...
当然，还有更多文件可以处理规则，设置游戏，GUI等内容。但是在这个简短的例子中，您可以看到我的项目如何变得非常大。这是常见的，用这种方式写东西吗？或者我应该简单地编写一个player.cpp文件，该文件包含多个类，在这种情况下，它们是相关的，并且会设置片段/颜色/王信息等。
答案 0 :(得分：3)
是的，将代码分发到多个文件是一种很好的做法，因为它可以使您的项目可维护。
我可以看到你对一个小项目的关注（开销值得吗？），但是在真正的大项目中，如果你不这样做，你最终会让人们永远滚动到一个大项目文件，并通过文件搜索找出他们正在寻找的东西。
尽量保持文件紧凑，每个文件一个类，每个类都很健壮，目标很明确。
有时，我们会将函数写入文件。为每个小的内联函数创建一个文件是不明智的，它会在没有理由的情况下增加文件数量。最好在文件中包含一系列函数（例如与打印相关的函数）。
最后，它可能基于意见，这是文件大小和数量之间的理想平衡，但我希望自己明确表达。
答案 1 :(得分：1)
您实际上提出了两个截然不同的问题：“将功能分成类的优秀粒度是什么”和“组织项目文件结构的良好实践是什么”。两者都相当广泛。
第一个问题的答案可能是遵循一个单一的责任惯用法。第二个问题的答案是使文件夹结构类似于命名空间结构（例如在boost中）。您当前将所有内容存储在src文件夹中的方法对C ++不利，因为当具有相同名称的类出现在不同的名称空间中时，它会导致更长的文件名以防止名称冲突。较大的项目确实往往有太多的文件，因为一个类需要4-5个文件。这导致了另一个为项目选择适当粒度的问题......
答案 2 :(得分：0)
人们往往担心很多关于＆＃34;太多的课程＆＃34;或者＆＃34;太多的文件＆＃34;，但这主要是历史遗留物。 40年前，当我们在打卡机上编写程序时，不得不携带大型托盘和盒子（而不是放下它们！），这肯定会引起关注。 35年前，你可以用于PC的最大硬盘是33MB，这是一个问题。今天，当你不考虑购买SSD少于512GB的PC，并且可以访问TB级和PB级的在线存储时，程序占用的文件数和字节数对于开发来说基本上是无关紧要的。处理。
这对我们人类意味着我们应该利用这种丰富的能力来改进我们代码的其他方面。如果更多文件可以帮助您更好地理解代码，请使用更多文件。如果较长的文件名可以帮助您更好地理解代码，请使用更长的文件名。如果遵循类似＆＃34;一个.cpp和一个.h文件的规则，每个类＆＃34;帮助人们维护代码库，然后遵循规则。关键是要关注真正重要的问题，例如什么使得我和我的团队能够使这些代码更易于维护，更易读，更易理解？＆＃34;
另一种解决方法是询问＆＃34;文件的数量＆＃34;是一个有用的指标，用于确定代码是否可维护？虽然对于应用来说显然太低的数字会令人担忧，但我无法告诉您10或100或1000是否是合适的数字（至少在不知道它们包含的类数量的情况下。）因此，它似乎不是一个有用的指标。
这是否意味着程序应该将1000个文件全部堆积到一个文件夹中，所有文件都编译并链接到单个库或可执行文件中？这取决于，但似乎同一命名空间中的1000个类会有点拥挤，并且由此产生的程序可能过于单一。在某些时候，您可能希望将架构重构为更小，更有凝聚力的包，每个包都有适当的责任区。当然，没有人可以告诉你这个神奇数字是什么，因为它完全取决于应用程序。但这不是驱动这样决定的文件数量，而是文件应该在逻辑上或体系上相互关联。
答案 3 :(得分：-1)
每个课程的设计和编程都应该完成一件事，而且只能完成一件事 因为每个类只设计一个责任，所以许多类用于构建整个应用程序