language-agnostic - 您在课程中允许的最大方法的限制 N 是多少？

Question

在填写面向对象概念调查（为一些学术研究人员提供软件设计的真实数据）时，我遇到了这个问题：

您在课程中允许的最大方法的限制 N 是多少？

然后调查继续询问一旦达到这个限制 N，你是否重构你的类。

老实说，我在设计我的应用程序时从未考虑过这样的限制，并且想知道这背后的原因是什么。为什么我想给自己设置一个可能非常依赖于类功能的任意数字？

Answer 1

您不必限制 N 的最大值。但你必须遵循“高凝聚力”原则。并且不要创建所有可以做任何事情的课程。

我想有一些 N 之后你应该开始担心。但这实际上取决于类本身及其主要目标。

Answer 2

有一个神奇的数字可以作为规则的基础，这种想法是那些渴望将秩序强加于宇宙的人通常过于敏感的想法超过了他们的理智。

也就是说，如果您在一个类中有超过 20 个左右的方法，则很有可能它做得太多并违反了SRP。

Answer 3

我也不会对事物进行任意限制，但我会说，一旦一个类的公共方法超过 10-20 个范围内的某个地方，我就会认真研究该类在做什么。回到我的 J2EE 时代，我们称它们为 Enterprise Java Melons。

相同的规则适用于各个方法的长度。我见过只有一两个方法的类，但每个方法都有数百行代码。

Answer 4

自从我开始将课程分解为单一职责以来，我通常不会接近它变得有问题的地方。

此外，一个设计良好的类可能有 30 个方法，而设计不佳的类可能有 3 个（嗯，30 正在推动它，但重点是——这甚至不一定是一个好的指标，有点像计算 kloc）

您的框架/语言也可能需要很多没有业务逻辑的方法。

计算其中包含业务逻辑的重要方法的数量可能会很有趣——我会说大约 4 或 5 个是合适的。

当我查看源代码时，我很惊讶 JDK 类中实际上有多少方法，但它们是如此糟糕，如此之小且如此易于阅读，以至于拥有 20 个根本不是问题。

Answer 5

就像其他人指出的那样，通常没有任意数量的方法，此时我会说“方法太多了！” 有时相反的情况可能同样糟糕，例如当一个对象有一个跨越数百行的整体式万能方法时。

话虽如此，如果我打开一个我以前没有看过的源文件并看到超过 10-20 种方法，我可能会扫描它，看看它是否不能以某种方式重构。