“经理”对象的麻烦

第一次查看旧项目时，我会扫描警告标志。我讨论了单例，过多的观察者，今天我将讨论“经理”类。

我必须重申这些是准则，而不是规则，在准则中，这不是关键。到那里的时候，这里的经理应该对审计进行审核。但是，如果您有诸如LoginManager，CacheManager和DataManager之类的许多类，则可能会遇到体系结构问题。

管理者可能是职责不明确的症状。当您考虑时，“经理”一词毫无意义。在面向对象的编程中，每个类都是一个管理器。可可触控可能具有UIApplicationManager，UIViewManager甚至是不起眼的NSStringManager。

与现实世界一样，最糟糕的经理人也始于善意。假设您的AvatarUploadController长超过3,000行，并且其中大多数内容都在处理，例如验证图像尺寸，调整图像大小，上载，检查网络错误等等。如果您将代码剪切并粘贴到另一个类中，并将其命名为AvatarManager，则它会继续进行。

现在退后一步，问为什么“大规模视图控制器”是个问题。这是单一责任原则。每个类都应负责单个功能。小型视图控制器很好，但是我可以使用大型视图控制器，只要它只能处理视图控制器的内容，例如设置视图层次结构和响应适应性变化。当您的控制器处理网络时，您就麻烦了。

将大量业务逻辑提取到AvatarManager中可以解决当前的问题。如果我们要说的是五十行代码，也许就足够了。但是，如果您要处理成千上万的业务逻辑，则将其包装在Manager中是半措施。您将扫帚扫入厨房，清理了客厅中的扫帚。

另一方面，管理者可能是人造面向对象设计的征兆。考虑一下NSFileManager，它实际上只是文件功能的集合。在真正的OO设计中，可以调用URL实例化NSFile（）对象，然后调用其remove（）方法，而不是调用removeItemAtURL（）。

这并不是说所有代码都必须是面向对象的，而是NSFileManager通过伪造它来破坏功能。它使用的是singleton defaultManager，因此存在有人（可能是随机的第三方库）分配给其委托属性的风险，并且搞乱了整个应用程序的文件操作。这真的比一组松散的文件功能要好吗？

我已经可以看到初级工程师单击“重构”按钮，准备将Manager与Broker，Coordinator，Utility等进行交换。这就是规则的问题：詹克找到了方法。

在审核Manager类时，请问：“该类负责什么？”如果您在回答问题时遇到问题，请问：“我可以将其分解吗？”在化身上载示例中，我将提取NetworkAPI ImageValidator ，ImageConverter等。

经理并不是一个大的危险信号，因为即使您知道自己在做什么，它也是一个容易退缩的名词。如果高级工程师坐在屏幕上想一个名字的时间太长，他们的“你太聪明”的感觉就会浮现。你不想成为那种在不提供任何东西的情况下继续关注美学的业余爱好者。

甚至Apple框架也使用名词，例如Core Location的CLLocationManager。嘿…让我们来上课吧！

它的职责是什么？它跟踪用户位置的更改。它承担太多责任吗？我不这么认为。我会担心它是否包含不相关的内容，例如反向地理编码。

好吧，我们可以重命名该类以澄清问题并消除责任感吗？我将使用CLLocationObserver或CLLocationTracker。真好！

除了苹果会在游戏后期重命名CLLocationManager之外。太多的旧代码依赖于此，即使您构建了代码迁移器来提供帮助，也很难证明在向用户交付功能时浪费时间在此上是合理的。

但是，如果您要构建持久的东西或建立任何类型的依赖关系，则值得花额外的几分钟时间在第一时间对事物进行命名。