oop - 在一个实体被认为臃肿之前，我们可以合理地将多少方法放入一个实体中？

Question

阅读所有关于单一职责原则、分解等的资料后，很难了解实体变得臃肿的警报信号应该是什么。

关于我们应该考虑最多多少种方法，或者是否有一些客观的其他标准，是否有一些好的建议/阅读某处？

Answer 1

在我看来， SOLID原则应该被视为指导方针，而不是严格的规则。SOLID 违规通常是设计问题的可靠指标。但有时它们是不可避免的。

有很多代码指标。从NDepends：

NbMethods：（为应用程序、程序集、命名空间、类型定义）方法的数量。方法可以是抽象、虚拟或非虚拟方法、在接口中声明的方法、构造函数、类构造函数、终结器、属性/索引器 getter 或 setter、事件添加器或移除器。不考虑在第三方程序集中声明的方法。

建议：NbMethods > 20 的类型可能难以理解和维护，但可能存在与 NbMethods 具有高值相关的情况。例如，System.Windows.Forms.DataGridView 第三方类有 1000 多个方法。

20 是 NDepends 作者认为的合理阈值。这是来自反对派的另一种观点：

该值应保持在 3 和 7 之间。这表明一个类有操作，但不是太多。大于 7 的值可能表示需要进一步的面向对象分解，或者该类没有一致的目的。值 2 或更小表示这不是一个真正的类，而仅仅是一个数据构造。

如您所见，这些指标非常主观。所以你必须决定什么对你和你的团队有意义。从 DDD 的角度来看，我发现使用值对象是减少实体 SRP 违规的一种非常好的方法。