管理器类是否可以作为不良体系结构的标志？

最近，我开始认为在您的设计中拥有很多经理类是一件坏事。这个想法还不够成熟，我无法提出令人信服的论点，但这里有几点要点：

• 我发现，要理解高度依赖“经理”的系统要困难得多。这是因为，除了实际的程序组件之外，您还必须了解使用管理器的方式和原因。

• 在很多时候，管理人员似乎常常被用来缓解设计问题，例如当程序员找不到一种方法来制作程序Just Work ^TM并不得不依靠管理人员类来使一切正常运行时。

当然，马槽可能很好。一个明显的例子是EventManager，这是我一直以来最喜欢的结构之一。：P我的观点是，经理似乎经常被滥用，除了掩盖程序体系结构的问题外，没有其他充分的理由。

经理班真的是不良建筑的标志吗？

出于以下几个原因，管理器类可能表明体系结构不佳：

• 毫无意义的标识符

  该名称FooManager没有说明类的实际作用，只是它涉及Foo实例。给班级一个更有意义的名称可以阐明其真实目的，这很可能导致重构。

• 小数责任

  根据单一职责原则，每个代码单元应仅用于一个目的。与经理一起，您可能人为地分担了责任。

  考虑一个ResourceManager协调Resource实例寿命和对实例的访问的。应用程序具有一个ResourceManager用于获取Resource实例的应用程序。在这种情况下，没有真正的理由可以解释为什么类中的ResourceManager静态方法不能提供实例的功能Resource。

• 非结构化抽象

  通常会引入经理，以抽象出与其管理的对象有关的潜在问题。这就是为什么管理者倾向于滥用它们作为设计不良的系统的创可贴。抽象是简化复杂系统的一种好方法，但是“ manager”这个名称并不代表它代表的抽象结构。真的是工厂，代理还是其他？

当然，出于同样的原因，管理者可以用的不仅仅是邪恶的。一个EventManager（实际上是一个）Dispatcher队列从源中排队事件，并将其分配给感兴趣的目标。在这种情况下，将事件的接收和发送责任分开是有意义的，因为个人Event只是一条消息，没有来源或目的地的概念。

我们写Dispatcher的Event情况下，对基本我们写了一个同样的原因GarbageCollector还是Factory：

经理知道不需要知道哪些有效载荷。

我认为，这是创建类似于经理的类的最佳理由。当您有一些行为类似于值的“有效载荷”对象时，该对象应尽可能愚蠢，以使整个系统保持灵活性。要为单个实例提供含义，您可以创建一个管理器，以有意义的方式协调这些实例。在任何其他情况下，管理人员都是不必要的。

经理可能是不良体系结构的标志，但通常更多的是，它们只是不能代表设计师为自己的对象提出更好的名称，或者只是反映英语这一事实。 （以及与此相关的任何人类语言）都适合交流日常的实用概念，而不是高度抽象，技术性很强的概念。

一个简单的例子来说明我的观点：在命名工厂模式之前，人们正在使用它，但是他们不知道如何调用它。因此，必须为Foo班级写一家工厂的人可能会叫它FooAllocationManager。这不是坏设计，只是缺乏想象力。

然后有人需要实现一个类，该类维护许多工厂，并将它们交给需要它们的各种对象。他FactoryManager之所以叫他的班级，是因为这个词Industry从未在他身上出现过，或者他认为这是不爽的，因为他从未在编程中听说过类似的东西。再次，缺乏想象力的情况。

具有很多“经理”类通常是一个贫乏的领域模型的征兆，其中领域逻辑从领域模型中升起，而是放置在管理器类中，该管理器类或多或少等同于事务脚本。这里的危险是，您基本上将恢复到过程编程-根据您的项目，这本身可能是好事，也可能不是好事-但是，没有考虑或故意使用它是imo的真正问题。

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

简短的回答：这取决于。

“管理器类”有几种不同的形式，其中有些是好的，有些是坏的，并且对于大多数而言，引入经理类是否正确，很大程度上取决于上下文。使他们正确的一个很好的起点是遵循单一责任原则 -如果您确切地知道每个经理班级负责什么（什么不负责），那么理解它们的麻烦就会少得多。

或者直接回答您的问题：这不是表示不良体系结构的管理器类数量，而是具有过多职责不明确或处理过多问题的经理类。

虽然可以很容易地说它们本质上是不良设计的指示，但它们可以通过在全球范围内普遍包含一项任务和职责来带来很多好处，并减少整个项目中的代码复杂性和其他样板代码。

尽管管理人员的盛行可能是由于对设计的判断力较弱，但他们也可能是要处理糟糕的设计决策或与组件化设计中的其他组件或第三方UI组件或具有奇怪接口的第三方Web服务之间的不兼容问题。作为例子。

这些示例说明了它们在某些情况下特别有用的地方，它可以通过将“丑陋的代码”封装在一个位置来降低总体复杂性并促进各种组件和层之间的松散耦合。不过，一个陷阱是，人们会觉得将管理人员设置为单身人士很有吸引力，我对此表示反对，当然，正如其他人所建议的那样，应该始终遵循“单一责任原则”。

管理器类是否可以作为不良体系结构的标志？

您回答了您的问题：它们不一定是不良设计的标志。

除了问题中带EventManager的示例外，还有另一个示例：在MVC设计模式中，演示者可以看作是模型/视图类的管理器。

但是，如果您滥用某个概念，则表示设计不良，可能还有体系结构不良。

当班级的名称中有“经理”时，请当心神 课问题（一个责任过多的人）。如果很难用名称来描述类所负责的事情，那就是设计警告标志。

除了糟糕的管理器类，我见过的最糟糕的名字是“ DataContainerAdapter”

“数据”应该是名称中那些禁止的子字符串中的另一个-都是数据，“数据”在大多数域中并不能告诉您太多信息。

经理类（就像几乎所有以“ -er”结尾的类一样）都是邪恶的，与OOP无关。所以对我来说，这是不良体系结构的标志。

为什么？“ -er”名称表示代码设计者采取了一些措施，并将其转换为类。结果，我们有了一个人为的实体，它没有反映任何有形的概念，而是一些行动。这听起来很程序化。

除此之外，通常此类会获取一些数据并对其进行操作。这是一种被动数据和主动过程的哲学，它在过程编程中占有一席之地。如果您意识到这一点，那么Manager类中没有什么不好的，但是那不是OOP。

对象思考意味着对象自己做事。发现您的领域，建立语义网，让您的对象成为活的有机体，聪明又负责任的人。

此类对象无需控制。他们知道该做什么和该怎么做。因此，Manager类两次违反了OOP原则。除了是“ -er”类之外，它还控制其他对象。但是，这取决于经理。由他控制-他是一个糟糕的经理。如果他能协调-他就是一个好经理。这就是为什么MVC中的“ C”字母应拼写为“协调人”的原因。

这个问题的正确答案是：

1. 这取决于。

编写软件时遇到的每种情况都是不同的。也许您所在的团队中每个人都知道经理班级在内部如何工作？不使用该设计将完全是疯狂的。或者，如果您试图将经理设计推向其他人，在这种情况下，这可能不是一个好主意。但这取决于确切的细节。