我目前在一个项目中有几个“经理”类，但是看到了很多建议您不要使用经理类，但在我的情况下似乎没有提供其他选择的东西。我有一个ClickManager，其中包含“可单击”对象的映射，以及一个ConfigManager，它负责加载和保存配置文件，因为config类来自我正在使用的API，并且太笨而无法加载自身。
在这些情况下，使用“经理”有哪些替代方案？
沃德·坎宁安（Ward Cunningham）曾经说过（1），每个程序员的办公桌上都应该有一个字典和一个同义词库。俗话说，计算机科学中只有两个难题：缓存失效和命名。（2）
关键是，命名事物很重要，很难，而且常常被忽略。这就是为什么围绕许多代码库命名Data和Manager乱扔类的原因。
这里至少有两个潜在的事情。一个是该类在做合理的事情，只需要给它加上一个简洁明了的描述性名称即可。例如，使用ClickManager，是否将事件调度到可点击对象？如果是这样，也许是Dispatcher。它会布置可点击对象吗？也许是Positioner。它是否包含可点击的对象（如Erwin Bolwidt所建议）？也许是Container。它是否执行某些操作以响应单击？也许是InteractiveCommand。有时，更具体地考虑一个班级为了想出一个好名字而做什么是有帮助的。
另一种可能性是，班级承担的责任过多，即违反了“ 单一责任原则”。这通常是很难命名的原因，因为它做了很多不同的事情。假设该类同时包含可单击的对象，将事件分派给它们，对其进行定位并执行命令。难怪除了Manager它正在执行所有这些相关但独立的功能之外，很难想出一个名称。（请注意，在许多UI工具包中，这些职责已分为不同的类。）
在这种情况下，建议将一个Manager大类重构为较小的类，每个类的责任更少（或更少）。为这些类想出更好的名称应该更容易。
（1）我认为这是十年前的一次OOPSLA。
（2）和一一失误。