将一个大类重构为许多小类

Question

我有一个很好的机会来重构旧的和“臭”的代码
进入一个设计得更好的班级大家庭。

我已经弄清楚、实施并测试了基本的设计框架。

然而，我已经达到了一个很大的“经理”类
它确实管理它应该管理的内容（让我们假设一些棘手的任务队列），
但它还负责一些其他的事情，这不是我上这门课的初衷。

创建一组新类

class OperationAPerformer
{
    void PerformA(input){...}
}

class OperationBPerformer
{
    void PerformB(input){...}
}

感觉不是正确的解决方案。 将OperationA、OperationB的逻辑保留在管理器类中 似乎没有良好的设计原因就夸大了 Manager 类

有什么建议吗？ 谢谢！

好的，所以我不能在这里发布我的所有代码 但基本设计（或骨架）

InitEventHandler  
SubmitEventHandler  
CancelEventHandler  
SuccessEventHandler  
FailureEventHandler  
ProgressReportedEventHandler  
TimeOutEventHandler

...
事件处理程序更新一些参数 并做一些管理工作，例如故障恢复后， UI参数更新之类的。OperationA

和OperationB是相关的，但弥补了很多代码 隐藏了相关操作类的主要框架

保存产品() 保存步骤A 保存步骤B ...

验证响应 验证A部分 验证B部分 ...

创建这样的类

class Validator
{
   public bool Validate(Response resp) {...}
   private bool PartA(...){...}
   private bool PartB(...){...}
}

似乎不合适，因为该类只是一组相关的方法... 创建一个类有足够的理由吗？

Answer 1

尺寸本身并不是一个必要条件；这只是一种“气味”，是调查是否应该更改代码的原因。

类的目的不是减少文件大小。它应该代表代码的组织原则。如果不同的操作自然地形成类别（理想情况下，因为它们在功能上具有内聚性，如 Pangea 所建议的那样，但除此之外出于任何合理的、可阐明的原因），则将其分解为单独的管理器类。

其他想法：

如果决策机制是数据驱动的，请考虑功能图：

interface Performer { public void perform(InputClass input); };
Map<String,  Performer> choices = new HashMap<String,  Performer>();
choices.put("choiceA", 
            new Performer() { public void perform(InputClass input) {
                // ... do action A
            });
choices.put("choiceB", 
            new Performer() { public void perform(InputClass input) {
                // ... do action B
            });

如果决策是由与执行操作的代码紧密相关的代码做出的，那么您可以重新考虑“执行”以表示“执行，如果您可以，如果不能请告诉我”：

interface Performer { public boolean perform(InputClass input); };
List<Performer> pipeline = new LinkedList<Performer>();
pipeline.add(new Performer() { public void perform(InputClass input) {
// ... do action A if you can
});
pipeline.add( new Performer() { public void perform(InputClass input) {
// ... do action B if you can
});

无论哪种方式，您都可以将配置密封在管理器内，将其暴露给主函数，甚至从配置文件驱动它。

如果上述情况都不成立，并且您的经理必须做大量固定数量的简单事情，请考虑硬着头皮让经理类用许多小的静态函数来膨胀。

Answer 2

您可以将GOD管理器类分解为多个“用例”管理器类，即单独的管理器类对于每个用例。这样，每个管理器类在功能上都是有凝聚力的，并且管理器类更改的原因只有一个（单一责任原则）。

如果你很难将其分成更小的类，那么这可能表明它已经具有凝聚力。