Oop 什么时候班级太大还是太小？

我最近让公司的一位高级开发人员审查了我的代码。他批评我的设计使用了太多的类。我很想听听你的反应

我的任务是创建一个服务，通过处理其他3个xml文件生成一个xml文件。让我们把它们命名为aaa.xml、bbb.xml和ccc.xml。这项服务分两个阶段进行。在第一阶段，它将aaa.xml与bbb.xml进行比较。在第二阶段，它将第一阶段的产品与ccc.xml合并以生成最终结果

我选择了一个包含三个类的设计：一个XmlService类，它使用了另外两个类，一个洗涤器类和一个合并类。我将清理类和合并类分开，因为这两个类都很大，并且具有不同的逻辑

我认为我的方法很好，因为它使我的班级保持了小规模和凝聚力。我的方法也有助于控制我的测试班的规模

高级开发人员断言，清理和合并类将仅由XmlService类使用，因此应该是它的一部分。他觉得这将使XMLService具有内聚性，这就是内聚性在他看来的含义。他还认为，以这种方式划分班级会使他们失去凝聚力

---

具有讽刺意味的是，我试图打破这些课程，以实现凝聚力。你怎么认为？谁对谁错？我们都对吗？感谢您的建议。

这是一个非常主观的方面，根据编码和样式指南以及批准您的代码的人的不同，这一方面会有所不同

这就是说，如果你的设计辩护站不住脚，而你的高级团队成员仍然坚持合并你的课程，那么你必须妥协：

---

你已经把逻辑分开了。编写一个服务类并像其他好的设计一样将方法分开，然后编写一个粘合方法。在每个方法上方添加一些注释，解释如果将来需要，如何轻松地将它们划分为多个类。

内聚性是衡量代码体中的功能相关性的一个指标。也就是说，如果合并和清理不是紧密相关的，那么将它们都包含在同一个类中会降低内聚性

这里也值得一提。创建一个类仅用于擦洗，另一个类仅用于合并遵循此原则

我认为你的方法是两者中比较好的

如果你遵循这个原则（根据你问题的语气，我认为你确实遵循了这个原则），那么答案是明确的：

当一个班级做了不止一件事时，它就太大了；及

当一个类不能达到它的目的时，它就太小了

这是非常宽泛的，而且确实是主观的——因此与你的同事发生了斗争。在你这方面，你可以说：

• 创建额外的类绝对没有问题——这是一个无问题的、编译和运行时方面的问题
• 该服务的当前实现可能表明这些类“属于”它，但这可能会改变
• 您可以分别测试每个功能
• 您可以应用依赖项注入
• 您可以减轻理解服务内部工作的认知负担，因为它的代码更小、组织更好

---

此外，我认为你的老板对凝聚力的理解是错误的。可以将其视为焦点：程序的焦点越窄，凝聚力就越高。如果附属类上的代码合并到服务类中，服务类的关注度就会降低（内聚性降低）。人们普遍认为较高的内聚力优于较低的内聚力。试着启发他/她的观点。

你会给这些课程起什么名字

ScrubXml

和

MergeXml

是很好的名称

ProcessXML

和

ScrubAndMergeXml

不是，第一个太一般，第二个有连接词。只要这些类中没有一个依赖于其中一个或其他类的内部结构（即低耦合），您就有了一个很好的设计

名称在确定内聚性方面非常有用。内聚模块只做一件事，因此有一个简单的特定名称。做一件以上事情的模块内聚性较差，需要更通用或更复杂的名称

---

如果X仅由Y使用，那么将X中的功能合并到Y中的一个问题是简化和荒谬：如果调用图是非循环的，那么您将在一个类中完成所有功能。

如果清除器和合并在主类的上下文之外没有意义，那么我同意您的审阅者的意见，特别是如果您必须公开任何实现细节以允许这种分离。如果您使用的是支持嵌套私有类或类似类的语言，那么这可能是一种合理的选择，可以在不向主类的外部使用者公开实现细节的情况下保持逻辑分离。

作为几年的GodClass building fest的参与者，现在正努力避免将来犯下这样的错误；使用单个类、250多个方法、200个数据字段和一些超过100行的方法制作一个6000到10000行的单源单元是一个错误，单责任原则看起来像是一个值得为你无知的主管的偏好辩护的东西

但是，如果您的主管和您在2000行代码属于一个类还是三个类的问题上存在分歧，那么我认为你们都比我更理智。也许这是一个规模和视角的问题。一些面向对象编程爱好者喜欢每个类都有一个特定的“独立系数”，这直接违反了人们普遍理解的关于如何提高内聚性和最小化耦合的思想

客观地说，一组三个类协同工作是一个更为客观的目标