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：

如果足够复杂，将子任务外包给帮助程序类。在这种情况下，我并不真正编码 interfaces 。

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更加好奇。我最终做了很多次。

Q1） 是否存在类似且可能更有效的现有模式？它不是责任链＆＃39;我正在寻找，因为我更喜欢这些组件是独立的（开放讨论）。它看起来更像是模板方法模式的可配置变体。

Q2） 我总是将主要课程命名为“SomethingController”和“＃39; SomethingController＆＃39;以及＆＃39; SomethingHelper＆＃39;和＃39; SomethingHelper＆＃39;或者＆＃39; SomethingComponent＆＃39;。我最近意识到＆＃39;控制器＆＃39;是误导和帮助＆＃39;没有信息。

对于正确命名这些类的想法非常有帮助。你怎么命名他们？

Q3） 你认为重构是否合理？

Q4） 主观：在helper方法中保留一些步骤并将一些步骤外包给helper类是否可以？我通常会限制自己对非公开方法进行单元测试。

Q5） 您是否认为辅助类（即没有代码到接口）是代码味道？可能我甚至可以将它们声明为内部类？

Answer 1

类的配置

这是合法的解决方案。有时可以看到春天的部分任务实现一些接口，通过spring magic，您可以使用

列出所有实现

@Autowired
List<MyInterface> myParts;

设计模式名称

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

类的命名

我会选择后缀.*Algorithm

将主要界面命名为DoSomethingComplicatedAlgorithm或DoSomethingComplicatedAlgorithmStep。实现接口的类将被称为WhatPartOfAlgorithmIsUsedHere

助手类

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

代码重构：外包子程序到辅助类

1 个答案:

类的配置

设计模式名称

类的命名

助手类