我目前在一个正在研究的项目中有几个“经理”课程但是已经看到很多建议你不要使用经理课程，但似乎没有在我的情况下提供任何替代方案。我有一个ClickManager，它包含一个“可点击”对象的地图和一个ConfigManager，它负责加载和保存配置文件，因为配置类来自我正在使用的API，而且加载本身太愚蠢了。
在这些情况下使用“经理”有哪些替代方案？
答案 0 :(得分：4)
关键在于命名事物很重要，而且很难，并且经常被忽略。这就是为什么有许多名为Data和Manager的类遍布许多代码库。
这里至少有两件可能发生的事情。一个是类正在做一些合理的事情，它只需要有一个好的，简洁的描述性名称。例如，使用ClickManager，它是否将事件分派给可点击的对象？如果是这样，也许它是Dispatcher。它是否布置了可点击的对象？也许它是Positioner。它是否包含可点击的对象（如Erwin Bolwidt建议的那样）？也许它是Container。它是否针对点击执行某些操作？也许它是InteractiveCommand。为了提出一个好名字，有时候有必要更具体地思考一个班级正在做什么。
另一种可能性是该类具有太多的职责，即它违反了Single Responsibility Principle。这通常是某些事情难以命名的原因，因为它有很多不同的东西。假设类同时包含可点击的对象，向它们调度事件，定位它们，和执行命令。毫无疑问，Manager之外的名称很难提出，因为它完成了所有这些相关但独立的功能。 （请注意，在许多UI工具包中，这些职责已分为不同的类。）
如果是这种情况，最好将一个大的Manager类重构为较小的类，每个类的责任较少（或一个）。为这些课程提供更好的名称应该更容易。
（1）我认为大约十年前这是在OOPSLA。
（2）并且有一个错误。