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

Question

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

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

Answer 1

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

有相当多的代码指标。来自 NDepends：

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

建议：NbMethods > 的类型20 可能很难
理解并维护，但在某些情况下可能是相关的
使 NbMethods 具有较高的价值。例如，
System.Windows.Forms.DataGridView第三方类有1000多个
方法。

20 是 NDepends 作者认为的合理阈值。以下是来自objecteering的另一个观点：

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

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