带有“Manager”的类型名称中 - 重构候选者？
我在论坛上找到了一篇论文：
如果您的类型中包含“经理” 这个名字，它是一个候选人 重构。
一个答案：
我知道它被认为是代码“气味”
所以...为什么？这篇论文正确吗？
那里有很多经理。例如，Ogre3d 就经常使用它们，而且这个引擎确实有一个干净的架构。
I found a thesis on forums:
If you have a type with "Manager" in
the name, it's a candidate for
refactoring.
One answer:
I know it's considered a code "smell"
So... Why? Is this thesis correct?
There are many managers out there. For example, Ogre3d uses them a lot, and this engine really has a clean architecture.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除了“经理”类之外，它在任何地方都可以。以 DefaultSceneManager 为例。这些是令人难以置信的庞大、需要“管理”的噩梦般的类。
问题是，大多数名称中包含“Manager”的类通常违反单一职责原则。这并不总是正确的——因为一个类可能只负责管理另一个方面，但通常情况下，这些方面的命名会有所不同。当一个类被称为“经理”时，通常是因为该类负责监督一切，并且实际上应该根据其各自的职责将其分解为不同的部分。
It does everywhere except the "manager" classes. Look at DefaultSceneManager as an example. These are incredibly huge, nightmarish classes to "manage."
The problem is that most classes with a name including "Manager" typically violate the Single Responsibility Principle. This isn't always true - as a class may have the single responsibility of managing one other aspect, but typically, those will be named differently. When a class gets the name "Manager", it's typically because it's the class overseeing everything - and really should be broken into distinct pieces based on their individual responsibilities.
经理做很多事情时都是有味道的。如果我们仔细研究管理器正在做什么，那么您可能会发现服务所做的很多事情。将它们拆分、分离并提取到不同的服务中是有意义的。
您还可以找到一些以 Manager 为后缀命名的 SRP 类，例如“ConnectionPoolManager”。如果它按照它所说的去做，这是有道理的。
A Manager when doing lot of things is a smell. If we carefully look into the Manager on what it is doing then you may find lot the things a service does. Splitting, separating them and extract into different a Services makes sense.
You can also find some SRP classes having named suffixed with Manager like 'ConnectionPoolManager'. This makes sense if it does what it says.