在填写The Object Oriented Concepts Survey（为一些学术研究人员提供软件设计的真实数据）时，我想到了这个问题：
您的类中允许的最大方法数的限制 N 是多少？
然后，调查会继续询问，一旦达到 N 限制，您是否会重构您的类。
老实说，我在设计我的应用程序时从未考虑过这样的限制，我想知道这背后的原因是什么。为什么我要给自己设置一个可能非常依赖于类功能的任意数字？
【问题讨论】：
标签： language-agnostic oop class-design
您不必限制 N 的最大值。但是您必须遵循“高凝聚力”原则。并且不要创建所有可以做任何事情的课程。
我想有一些 N 之后你应该开始担心了。但这实际上取决于类本身及其主要目标。
【讨论】：
我们可以根据一个神奇的数字来制定规则的想法是那些渴望将秩序强加于宇宙的人通常过于敏感的想法。
也就是说，如果您在一个类中有超过 20 个左右的方法，则很有可能它做得太多而违反了 SRP。
【讨论】：
我也不会对事物进行任意限制，但我会说，一旦一个类的公共方法超过 10-20 个范围内的某个地方，我就会认真研究该类在做什么。在我的 J2EE 时代，我们称它们为 Enterprise Java Melons。
相同的规则适用于各个方法的长度。我见过只有一两个方法的类，但每个方法都有数百行代码。
【讨论】：
自从我开始将课程分解为单一职责后，我通常不会接近有问题的地方。
另外，一个设计良好的类可能有 30 个方法，而一个设计不佳的类可能有 3 个（嗯，30 正在推动它，但重点是——这甚至不一定是一个好的指标，有点像计算kloc）
您的框架/语言也可能需要很多没有业务逻辑的方法。
计算其中包含业务逻辑的重要方法的数量可能会很有趣——我会说大约 4 或 5 个是合适的。
当我查看源代码时，我很惊讶 JDK 类中实际上有多少方法，但是它们被破坏得如此之好，如此之小且如此易于阅读，以至于拥有 20 个根本不是问题.
【讨论】：
就像其他人指出的那样，通常没有任意数量的方法，此时我会说“方法太多了！”有时相反的情况可能同样糟糕，例如当一个对象有一个跨越数百行的整体式万能方法时。
话虽如此，如果我打开一个我以前没有看过的源文件并看到超过 10-20 种方法，我可能会扫描它，看看它是否不能以某种方式重构。
【讨论】：