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

Question

在填写The Object Oriented Concepts Survey时（为了向一些学术研究人员提供有关软件设计的真实数据），我遇到了这个问题：

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

然后，调查继续询问您是否在达到此限制N后重构课程。

在设计我的应用程序时，我真的从没想过这样的限制，并想知道这背后的原因是什么。为什么我要自己强加一个可能非常依赖于类功能的任意数字？

Answer 1

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

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

Answer 2

我们可以建立一个规则的神奇数字的想法是，那些希望对宇宙施加秩序的人超过他们的意识的通常的娇气。

也就是说，如果一个班级中有超过20个左右的方法，那么它很有可能做得太多而且违反了SRP。

Answer 3

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

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

Answer 4

由于我开始将课程分解为单一职责，因此我通常不会接触到有问题的地方。

另外，精心设计的类可能有30种方法，而设计不佳的类可能有3种（Umm，30就是推动它，但重点是 - 这不一定是一个很好的指标，有点像计数kloc）

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

计算其中包含业务逻辑的非平凡方法的数量可能会很有趣 - 我会说4或5左右是合适的。

当我查看源代码时，我很惊讶JDK类实际上有多少种方法，但是它们很破碎，如此之小，很容易阅读以至于根本没有问题20

Answer 5

像其他人一样指出，通常没有一些任意数量的方法，在这一点上我会说“那太多方法！”有时相反的情况也同样糟糕，例如当一个对象具有跨越数百行的单片do-everything方法时。

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