一个类方法的数量限制是多少？

在我读过的不同设计书中，有时会着重强调类必须具有的方法数量（考虑OO语言，例如java或C＃）。这些书中报道的例子通常非常简洁明了，但很少涉及“严重”或复杂的案例。
但是范围似乎在5到8之间。

在一个项目中，我开发了一个类别为“ Note”的类，其属性为属性：Title，Desctiption，CreateDate等。
然后是一些基本方法，例如：getRelations（如果将注释分配给了不同的文档），getExpiryDate等。

但是，在开发应用程序时，需要更多的功能，因此需要更多的方法。

我知道，一个类拥有的方法越少，耦合就越松散。就模块化和可重用性而言，这确实是一个很好的优势，而且更易于编辑。
顺便说一句，如果在我们的上下文中不需要（甚至没有意义）创建子类，并且所有需要的功能都与该类相关，那么我们可以进一步附加几个方法？

我同意拥有15种以上的方法，然后可能需要重新设计。
但是即使在那种情况下，如果删除某些方法或继承不是一个选择，那将是正确的方法吗？

有您需要的方法。如果可能的话，我会尽量将公共方法的数量减少到5-8条规则。老实说，大多数人面临相反的问题，他们有疯狂的超级方法，需要更多而不是更少地加以分解。您实际上有多少个私人助手方法并不重要。实际上，如果您在Java中使用的方法不超过8种，则可以使用仅具有构造函数，toString和3个属性的getter / setter的类来达到极限，这并不是一个可靠的类。最重要的是，不必担心您的类有多少种方法。担心确保您的课程不会涉及无关的问题，并确保您拥有一个合理的，易于理解的公共接口。

答案很简单：将所有内容放在属于其职责的类中，但是在分配职责时要小心。

有时，大班是由不同职责的小班组成的。

通常，当类的用法或维护变得笨拙时，我尝试将职责划分为较小的类。我很少有超过500行的课程。我最大的班级大约有1.5k阵地。

您根本无法陈述诸如“一个类应该在n和m个方法之间”的一般规则。

没有理由（在OO设计中）仅拥有太多方法。具有较少方法的类更好地分离也是不正确的。

例如，查看java.lang.String类。很多方法，因为一个字符串可以做很多事情。尽管如此，耦合并不强烈。

我不知道为什么像15这样的魔术数字可以区分好设计和坏设计。不，这不是那么容易。

在PMD中，TooManyMethods规则的默认行为是将具有10个或更多方法的类识别并标记为潜在错误。不过，这只是一个任意数字。它很容易在配置中更改。无论这个数字是多少，它都只是开发人员查看类并查看是否存在问题的标志，而不是它有问题。

更具体一点的可能是7加减2规则。这说明人的思想可以在记忆中容纳和理解5到9个“对象”。读取特定类时，对象很可能是构成该类的方法和字段。然而，类经常有超过9个字段和方法，即使你不指望存取，存取器和任何标准操作（例如，toString()，hashCode()，和equals()Java中）。

最相关的措施是扇入和扇出，以及耦合和内聚的讨论。该单一职责原则和关注点分离应适用-一类应该做的，或者代表一两件事，独自一两件事。这些比在评估设计或实现时尝试将数字分配给最大/最小方法要好得多。