关于如何减少“经理”类使用的提示/建议？

有时，我听说程序设计中有太多“管理器”类是代码的味道，并增加了不必要的复杂性。对我而言，人们想使用管理器类从对他们有意义的上下文中使用对象来控制和控制对象是有道理的，但是弄清楚如何使解决方案在没有它们的情况下有效。

真的应该尽可能避免经理班吗？另外，对于应删除这些管理人员的一般/常见情况，我应该阅读哪些文章/论文，以了解如何实施替代方法？

这可能有两个原因，这是代码气味。原因之一是，这可能意味着您没有域对象，而是拥有仅存储要由控制器或管理器类进行操作的数据的值对象。这实际上很常见，相当于使用OO语言进行过程编程。“大量管理人员”可能暗示您需要将状态逻辑，验证和其他直接关注事项集成到域对象中，以便它们实际上封装某些内容。当然，还有更大的提示，例如您除了getter / setter之外没有其他方法。

其代码气味的另一个原因是，这可能意味着您的域对象实际上彼此之间没有很好的关联。例如，如果您有一个Account类，但实际上它对Transaction类一无所知，只是它被命名为Transaction，并且可以有多个类，那么您又没有真正活跃的业务域实现。例如，如果关闭accountStatus，SavingsAccount可能应该知道它不能接受DebitTransaction。许多实现将使这留给经理。

拥有很多“经理”类通常是 领域模型，其中领域逻辑从领域模型中而是放置在经理类中，后者或多或少等同于事务脚本。这里的危险是，您基本上将恢复到过程编程-根据您的项目，这本身可能不是好事，但是实际上，“代码气味” imo并未被考虑或故意使用，这是事实。

遵循“信息专家”的原则，逻辑操作应驻留在尽可能接近其所需数据的位置。这将意味着将域逻辑移回域模型，从而使这些逻辑操作对域模型的状态产生可观察的影响，而不是由事务脚本从外部更改域模型的状态。

管理器类的最大问题是，它们仅代表了类应该做什么的模糊概念。如果您称某个经理为经理，那么它可以做任何与它所管理的事情有关的一切事情。我想在某些情况下可能还可以，但我会说在几乎所有情况下这都不是您想要的。您希望某人能够查看类名称，并且不仅要对类的作用有一个精明的主意，而且还要对它不做的有一个精明的主意。

管理器类的另一个问题是，很难决定应将功能移至何处。当管理器类很多时，管理器类之间的功能通常会重叠很多。然后，您必须确定哪个类应该实现该重叠功能，并且当然其他人会选择不同的方式。因此，当他们寻找功能并没有在期望的位置看到它时，他们便继续进行并在他们认为属于的位置重新实现它，因为他们不知道其他实现的存在。换句话说，经理班级导致难以理解且经常使设计复杂化。