适当使用静态方法

从概念上讲，当方法仅接受输入并将输入重新格式化为输出时，使用静态方法 (C#) 是否合适？例如：

public static string FormatString(string inputString){
  return "some formatting" + inputString + "Some other formatting";
}

如果我有一些这些类型的方法，静态“实用程序”类是个好主意吗？

到目前为止，我同意其他答案，因为它在很多时候确实有意义。

有时，您可能实际上想通过定义接口并使用实例方法实现它来给自己更多的灵活性。这使您可以选择使用不同的代码中的方法。

这是我的意思的一个例子。假设你正在使用这个formatString你的方法在某些地方的代码看起来像这样：

public void DumpToConsole()
{
    foreach (DataField field in m_fields)
    {
        Console.WriteLine(StringUtils.formatString(field.ToString()));
    }
}

好的，这太棒了。 （实际上，这很愚蠢，但无论如何 - 仅用于说明！）但是您可以通过让它接受界面，其中您可能有各种实现，它们提供完全不同类型的格式：

public void DumpToConsole(IFormatter<DataField> formatter = null)
{
    // Perhaps you could specify a default. Up to you.
    formatter = formatter ?? Formatter<DataField>.Default;

    foreach (DataField field in m_fields)
    {
        Console.WriteLine(formatter.Format(field));
    }
}

然后代替StringUtils作为一个静态实用程序类，它只是one提供一种格式化某种类型对象的方法的类的实现（在您的情况下，string物体；在我的例子中，这些想象的DataField对象）。

所以这都是一种非常冗长的说法，这取决于情况。如果您的目标是未来获得超级灵活性，maybe您应该考虑实现一个接口，而不是使用静态帮助器类。

请注意，在我上面的示例中，解决问题的另一种完全可接受的方法可能是接受Func<T, string>代表而不是这个假设IFormatter<T>界面。在我看来，这主要是一种风格选择。但当您想要自定义多种行为时，界面通常会变得更加现实；也就是说，与接受单个接口相比，定义接受 3 个、4 个或更多委托的方法很快就会变得很麻烦。