什么时候一个类太大了？

Question

我倾向于创建具有30-40个(或更多)方法的非常大的类。有多少个方法才算太多？有没有什么“气味”或经验法则可以使用？

Answer 1

第一步是遵守Single Responsibility Principle。如果你不能用一句话说出你的类是做什么的，那么它可能做得太多了。

一旦你缩小了范围，我不知道方法的数量是否真的重要，只要你的方法是don't do too much的。

Answer 2

我会咬人的。除了涉足O-O设计的深水区之外，我不做更多的事情，我将介绍几条我的经验法则：

1. 静态属性是非常值得怀疑的。强烈质疑自己是否真的需要它们。
2. 类的大多数属性/属性应该是私有的(只能由对象实例访问)或受保护的，只能由类的实例或派生类(子类)的实例访问。
3. 如果类的属性/属性对一般公众可见，则它最有可能是只读的。在大多数情况下，对象实例的状态只能通过响应请求它做一些有用的事情的方法来改变(例如，你请求窗口自己移动，而不是显式地设置为坐标平面上的原点)。
4. 公共Getter/Setter方法或属性是有问题的，因为它们主要公开对象状态(参见上面的第2项)。
5. 公共方法应该主要公开对象实例响应的逻辑操作(消息)。这些操作应该是原子的(例如，对于处于逻辑上一致的内部状态的对象，它不应该依赖于外部参与者向其发送特定的消息序列)。对象状态应该改变是响应这些消息的结果，并且应该被暴露为消息的副作用窗口(例如，将其位置报告为请求其移动的副作用的窗口是acceptable).

(

上面的代码应该会大大减少对象的公共接口。

最后，如果您的对象有多个消息需要响应，那么您很可能有一个重构的候选对象:它真的是一个整体对象，还是离散对象的集合？当然，“不止几个”是一个高度主观(和上下文相关)的数字--我将把10-12作为一个合理的限制。

希望这能有所帮助。

有很多关于面向对象设计、分析和建模的书籍。

Answer 3

正如其他人所说，当一个类试图做不止一件事情和violates the Single Responsibility Principle时，它就太大了。

关于这个主题和其他主题的一本优秀的书(我强烈推荐给任何开发人员)是Bob Martin的Clean Code。