java - 代码重构: Outsourcing substeps to helper classes

Question

当一个类执行复杂而冗长的任务时，我通常会根据情况逐步重构它，如下所示。

版本 0

public class ComplicatedTaskDoer{

    public void doComplicatedTask(){
      // lots of complicated code
    }

}

版本 1:

将其分解为多个较小的子任务

public class ComplicatedTaskDoer{

    public void doComplicatedTask(){
      init();
      doSubStepA();
      doB();
      doC();
      wrapUp();
    }
}

版本 2:

如果足够复杂，请将子任务外包给辅助类。在这种情况下，我并没有真正编写接口(interface)代码。

public class ComplicatedTaskDoer{

    public void doComplicatedTask(){
      init();
      subsetpADoerClass.doA();
      classB.doB();
      classC.doC();
      wrapUp();
    }
}

版本 3:

如果我发现自己将来需要添加更多组件，并且输入和输出对象方面存在有效模式，我会执行以下操作。

public class ComplicatedTaskController{
    //injected
    List<SomethingHelperComponent> components;
    public void doComplicatedTask(){
      init();
      for(SomethingHelperComponent component : components){
           component.process(commonInput);
      }
      wrapUp();
    }   
}

我对版本 3 更好奇。我最终这样做了好几次。

第一季度) 是否存在类似且可能更有效的现有模式？我正在寻找的不是“责任链”，因为我更喜欢这些组件是独立的(开放讨论)。它看起来更像是模板方法模式的可配置变体。

第二季度) 我总是将主类命名为“SomethingController”，将辅助类命名为“SomethingHelper”或“SomethingComponent”。我最近意识到“控制者”具有误导性，而“帮助者”则没有提供任何信息。

获得一些关于正确命名这些类的想法真的很有帮助。你怎么命名它们？

第三季度) 您认为重构合理吗？

第四季度) 主观:在辅助方法中保留某些步骤并将某些步骤外包给辅助类是否可以？我通常避免对非公开方法进行单元测试。

Q5) 您是否认为辅助类(即没有代码到接口(interface))是一种代码味道？也许我什至可以将它们声明为内部类？

Answer 1

类的配置

这是合法的解决方案。有时会在 spring 中看到部分任务 实现一些接口(interface)，通过 spring magic 你可以得到所有实现的列表

@Autowired
List<MyInterface> myParts;

设计模式名称

至于命名，我认为您可以将其视为责任链的特例。它可能不太准确，但很好地表达了您的意图。

类的命名

我会选择后缀.*算法

将主接口(interface)命名为DoSomethingComplicatedAlgorithm或DoSomethingComplicatedAlgorithmStep。实现接口(interface)的类将被称为 WhatPartOfAlgorithmIsUsedHere

帮助类

如果它们可以让您避免代码重复，并且您没有比使用它们更好的域模型。另一方面，将其作为最后的选择。可能是小代码味道，但你的应用程序肯定不会被烧毁。