oop - 什么时候类(class)太大或太小？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

3年前关闭。




Improve this question




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

我的任务是创建一个服务，该服务通过操作其他 3 个 xml 文件来生成一个 xml 文件。我们将这些命名为 aaa.xml、bbb.xml 和 ccc.xml。该服务分两个阶段进行。在第一阶段，它将 aaa.xml 与 bbb.xml 擦洗。在第二阶段，它将第一阶段的产品与 ccc.xml 合并以产生最终结果。

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

我认为我的方法很好，因为它使我的类(class)小而有凝聚力。我的方法也有助于控制我的测试类的大小。

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

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

Answer 1

如果您关注 single responsibility principle (根据你的问题的语气，我认为你确实遵循它)，那么答案很明确:

当一个类做不止一件事时，它就太大了；和

当一个类无法实现其目的时，它就太小了。

这是非常广泛的，确实是主观的——因此与你的同事发生了争执。在你这边，你可以争辩:

创建额外的类绝对没有问题——这不是问题，编译和运行时都是如此。

该服务的当前实现可能表明这些类“属于”它，但这可能会改变。

您可以分别测试每个功能。

您可以应用依赖注入(inject)。

您可以减轻理解服务内部工作的认知负担，因为它的代码更小且组织更好。

此外，我认为你的老板对凝聚力的理解是错误的。把它想象成 关注 :你的节目的焦点越窄，凝聚力就越高。如果卫星类上的代码合并到服务类中，则后者变得不那么集中(不那么有凝聚力)。人们普遍认为，较高的内聚力优于较低的内聚力。尝试启发他/她对此的看法。