避免班级成为神级的做法是什么？

Question

让我们举一个Consumer类的例子。与消费者相关的功能将进入此类。消费者类逐渐有很多方法。这些应该是Consumer类本身的一部分。在这种情况下，我们如何打破它？有没有解决这个问题的策略？

Answer 1

使用结构设计模式。我会使用Composite或Decorator设计模式来解决您的问题。您可以在此处了解相关信息：https://sourcemaking.com/design_patterns/structural_patterns

Answer 2

这是一个相当广泛的问题，但我会尝试回答它。

SOLID principles是值得遵循的良好做法。如果你应用这些，特别是单一责任原则，你最终会得到一个责任明确的小班。

查看cohesion也很重要，它可以衡量班级元素的相关性。您希望在课程（和模块）中实现高凝聚力。例如，如果类中的每个方法都使用某个成员变量，那么内聚力很高。如果你的类的成员变量只在一个方法中使用，那么这是一个很好的例子，可以重构成一个单独的类。

Answer 3

正如@MoonMoo已经公开的那样，重构 fat <​​/ em>类的指导原则应该是SOLID原则和类的凝聚力。
关键是： 即使某个方法与客户相关，它是否应该保留在客户类中？
或者客户可以从另一个类调用该方法吗？
这些问题的答案可能是了解哪些方法必须保留在Customer类中以及哪些方法可以在另一个类中重新定位到客户可以参考的另一个类中的第一个起点。