要设计一个复杂的方法，我应该引入一个助手类吗

本文关键字：一个 我应该 复杂 方法 | 更新日期: 2023-09-27 18:29:35

通常，当我想创建一个复杂的方法a时，为了将其分解成更小的部分，我会使用一个助手类ClassA，并像这样调用它

  Public T MethodA()
      {
        ClassA myClass = new ClassA(some parameter);
        return myClass.Output();
      }
  Class ClassA
  {
      T fields...
      Public ClassA(some parameter)
         {
             Initialize(some parameter)
             DoA();
             DoB();
         }
      Public T Output()
         {
             DoC();
         }
      void DoA();
      void DoB();
      ...
  }

所以实际上ClassA只是一个巨大方法的包装。我觉得为了实现这一点而创建一个实例是一种浪费。我应该让它静止吗？

它的最佳设计模式是什么？

要设计一个复杂的方法，我应该引入一个助手类吗

所以第一个问题是说"巨大的方法"。这告诉我你需要把它分解成更小的方法，每个方法都有特定的目的。你可以调用这个方法，它会调用较小的方法，但如果你有一个方法，它说

  1. 调用数据库
  2. 修改记录
  3. 对它们进行排序
  4. 将它们分组到另一个结构中

这应该是对象中不同的方法，每个方法都有自己的函数。这使得以后在代码中出现错误时更容易进行测试和调试。

第二个是，你不需要为一个方法创建一个对象——你可以始终使该方法为静态的，这样你就不需要实例化一个新对象来调用它。看起来你把你的逻辑放在了我要重构的构造函数中。如果你要返回它的输出，只需使它，这样你就可以做：

var myObject = new MyObject();
var results = myObject.DoFunction();

您不需要将逻辑放入构造函数中，然后为结果调用另一个方法。构造函数应该具有使对象运行所需的最少代码量，然后让调用方法选择何时希望该对象执行业务逻辑。

如果它符合"SOLID"原则的单一责任，那么它就可以了。

构造函数中传递的参数通常是类的不可变属性/成员。

您也可以将其设置为静态，但这将导致硬依赖，这是不鼓励的。

另一种选择是使用函数编程实践，它将定义如下（假设A和B是类型）：

var func = (A a) => return new B();

在现有类或静态类上使用静态方法。

public static void Output(param)

答案实际上在于标签"面向对象"。如果你想以oop的方式设计一些东西，你必须把方法放在该方法操作的主要对象的类中

您想要做的是在像C#这样的纯面向对象的语言中使用过程方法。有多种可能的方法可以做到这一点：

  • 如前所述，您可以创建一个"工具"类，其中包含没有特别链接到对象类的方法。然后，这个工具类提供一个或多个静态方法。这将是最接近于在过程语言中实现它的方式
  • 如果您主要担心的是该方法太大，无法将其包含在应该链接的对象类中，请首先考虑将该方法分解为更小的部分，然后考虑将其实现为对象类的扩展方法（可以在类外定义）
  • 最后，如果有一个对象确实有意义，但您不想每次使用它都创建一个新实例，那么可以使用singleton模式使类只有一个实例，该实例可以通过静态方法使用

根据你的具体问题，做你想做的事情可能还有其他明智的方法。

如果我是你，我不会调用构造函数中的任何方法。一个好的编程实践是构造函数不应该抛出异常。

在创建课程之前，我会问自己一个问题。"我会在其他地方使用这些方法吗？"如果答案是肯定的，那么我将创建一个类。如果否，我更愿意将其作为实现细节，并使那些Private方法。因为这是类的实现细节。

通常当我想创建一个复杂的方法

等等，我认为你是从错误的角度来处理这个问题的。通常，您希望实现某种功能，而不是复杂的方法。

当您意识到这一点时，您可以采用功能的显式或隐式规范，并将其分解为方法/类/组件/服务/任何东西。

现在，如果你正在重构某个东西，将方法移动到不同的类可能是帮助你的第一步，但我会选择一种类似于Kevin所描述的方法，当你在过程中确定不同的责任时，将其拆分为多个方法，或者可能是类。

用一个单独的类结束是完全可以的，但我会更进一步，问"它代表什么概念"？

如果你能为这个类找到一个好名字，这表明它是隐藏在你的设计中的真正想要"退出"的东西。通过给它一个名字和在设计中的位置，你可以更好地谈论它，推理它，甚至可能找到它的其他用途。你让事情变得更明确、更容易理解，这是一件好事。从那里你可能会发现，始发类实际上不需要知道新类的实现细节，只关心它的interface。祝贺您，您在设计中发现了另一个概念，它可以用于从概念上和物理上隔离关注点。

从重构的角度来看，这个过程就是Michael Feathers在《有效地使用遗留代码》一书中所说的萌芽类。它用于将逻辑划分为可测试、独立和可理解的块。

相关文章：