只做一件事的类的模式

假设我有一个程序可以执行以下操作：

void doStuff(initalParams) {
    ...
}

现在，我发现“做事”是相当复杂的操作。该过程变得很大，我将其拆分为多个较小的过程，很快我意识到在进行填充时具有某种状态会很有用，因此我需要在较小的过程之间传递较少的参数。因此，我将其纳入自己的类中：

class StuffDoer {
    private someInternalState;

    public Start(initalParams) {
        ...
    }

    // some private helper procedures here
    ...
}

然后我这样称呼它：

new StuffDoer().Start(initialParams);

或像这样：

new StuffDoer(initialParams).Start();

这就是感觉不对的地方。使用.NET或Java API时，我始终不会调用new SomeApiClass().Start(...);，这使我怀疑自己做错了。当然，我可以将StuffDoer的构造函数设为私有，并添加一个静态辅助方法：

public static DoStuff(initalParams) {
    new StuffDoer().Start(initialParams);
}

但是然后我有了一个其外部接口仅包含一个静态方法的类，这也感觉很奇怪。

因此，我的问题是：这种类型的类是否有公认的模式？

• 只有一个入口
• 是否没有“外部可识别”状态，即实例状态仅在执行该入口点时需要？

有一种称为“ 方法对象”的模式，您可以在其中将一个带有多个临时变量/参数的大型方法分解为一个单独的类。您执行此操作，而不只是将方法的一部分提取到单独的方法中，因为它们需要访问局部状态（参数和临时变量），并且您不能使用实例变量共享局部状态，因为它们对于该方法而言是局部的（以及从中提取的方法），其余对象将不再使用。

因此，方法改为成为自己的类，参数和临时变量成为该新类的实例变量，然后将该方法分解为新类的较小方法。生成的类通常只有一个公共实例方法，该方法执行该类封装的任务。

我要说的是，所讨论的类（使用单个入口点）经过精心设计。易于使用和扩展。相当扎实。

同样的事情no "externally recognizable" state。这是很好的封装。

我看不到类似代码的任何问题：

var doer = new StuffDoer(initialParams);
var result = doer.Calculate(extraParams);

从SOLID原则的角度来看，jgauffin的答案很有意义。但是，您不应忘记一般的设计原则，例如信息隐藏。

我发现了使用给定方法的几个问题：

• 正如您指出的那样，当创建的对象不管理任何状态时，人们不会期望使用'new'关键字。您的设计反映了它的意图。使用类的人可能会困惑于它管理的是什么状态，以及随后对该方法的调用是否会导致不同的行为。
• 从使用类的人的角度来看，内部状态被很好地隐藏了，但是当您想对类进行修改或仅仅理解它时，您会使事情变得更加复杂。我已经写了很多关于拆分方法（使它们变小）的问题，尤其是在将状态转移到类范围时。您正在修改API的使用方式，以便具有更小的功能！我认为这绝对是太过分了。

一些相关参考

争论的主要点可能在于“ 单一责任原则”的延伸范围。“如果将它推到极致并建立有一个理由存在的类，则每个类可能只会得到一个方法。这将导致即使是最简单的过程也需要大量的类，从而导致系统成为难以理解且难以改变。”

与此主题相关的另一个相关参考：“将程序划分为执行一个可识别任务的方法。使方法中的所有操作都处于相同的抽象级别。” - 肯特·贝克这里的关键是“抽象的同一水平。” 这并不意味着“一件事”，因为它经常被解释。此抽象级别完全取决于您要设计的上下文。

那么正确的方法是什么？

在不知道您的具体用例的情况下，很难分辨。在某些情况下，我有时（不经常）使用类似的方法。当我想处理数据集时，不想让整个类范围都可以使用此功能。我写了一篇关于它的文章，文章介绍lambda如何进一步改善封装性。我也在程序员这个话题上提出了一个问题。以下是我使用此技术的最新示例。

new TupleList<Key, int>
{
    { Key.NumPad1, 1 },
            ...
    { Key.NumPad3, 16 },
    { Key.NumPad4, 17 },
}
    .ForEach( t =>
    {
        var trigger = new IC.Trigger.EventTrigger(
                        new KeyInputCondition( t.Item1, KeyInputCondition.KeyState.Down ) );
        trigger.ConditionsMet += () => AddMarker( t.Item2 );
        _inputController.AddTrigger( trigger );
    } );

由于内部的“本地”代码ForEach不会在其他任何地方重用，因此我可以将其保留在与之相关的确切位置。在我看来，以这样一种方式对代码进行概述：将相互依赖的代码紧密地组合在一起，使其更具可读性。

可能的选择

• 在C＃中，您可以改用扩展方法。因此，您直接传递给该“一件事”方法就可以对参数进行操作。
• 查看此函数是否实际上不属于另一个类。
• 使它成为静态类中的静态函数。这很可能是最合适的方法，正如您所引用的常规API中所反映的那样。

我会说这很好，但是您的API仍应该是静态类上的静态方法，因为这正是用户所期望的。静态方法用于new创建您的帮助对象并完成工作的事实是一个实现细节，无论调用该对象的人都应该隐藏该实现细节。

new StuffDoer().Start(initialParams);

无能的开发人员可能会使用共享实例并使用它，这是一个问题

1. 多次（如果以前（可能是部分）执行不会干扰以后的执行，则可以）
2. 从多个线程（不是很好，您明确地说它具有内部状态）。

因此，这需要明确的文档，它不是线程安全的，并且如果它是轻量级的（创建速度很快，不会占用外部资源或大量内存），则可以即时实例化。

将其隐藏在静态方法中将对此有所帮助，因为这样就永远不会重复使用该实例。

如果它具有一些昂贵的初始化，则可以（并非总是）准备一次初始化并多次使用它，这是有益的，方法是创建另一个仅包含状态并使其可克隆的类。初始化将创建将存储在中的状态doer。start()将其克隆并将其传递给内部方法。

这也将允许其他事情，例如持久执行部分执行的状态。（如果花费很长时间并且外部因素（例如电力供应故障）可能会中断执行。）但是通常不需要这些额外的花哨的东西，因此不值得。

除了我更详尽，个性化的其他答案外，我觉得以下观察值得单独回答。

有迹象表明您可能正在遵循Poltergeists反模式。

Poltergeists是具有非常有限的角色和有效生命周期的课程。他们经常启动其他对象的处理。重构的解决方案包括将责任重新分配给寿命更长的对象，从而消除了Poltergeists。

症状和后果

• 冗余导航路径。
• 瞬态关联。
• 无状态类。
• 临时的，短期的对象和类。
• 仅用于通过临时关联“播种”或“调用”其他类的单操作类。
• 具有“类似控件”操作名称的类，例如start_process_alpha。

重构解决方案

捉鬼敢死队通过将Poltergeists完全从类层次结构中删除来解决他们。但是，在删除它们之后，必须替换poltergeist“提供”的功能。只需进行简单的调整即可校正体系结构，这很容易。

在EAA目录的 Martin Fowler的P中可以找到几种模式。

1. 事务脚本：与您提到的方法有些相似。
2. 带有方法对象的替换方法：@anon提到的方法看起来也不错。