适当使用静态方法

Question

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

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

如果我有一些这样的方法,静态"实用"类是一个好主意吗？

Answer 1

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

\n\n

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

\n\n

这是我的意思的一个例子。假设你正在使用这个formatString您的这种方法，如下所示：

\n\n

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

\n\n

好的，这太棒了。（实际上，这很愚蠢，但无论如何 \xe2\x80\x94 仅用于说明！）但是您可以通过让它接受接口来使这种方法更加灵活来使这种方法更加灵活，您可能有各种实现来提供完全不同类型的格式：

\n\n

public void DumpToConsole(IFormatter<DataField> formatter = null)\n{\n    // Perhaps you could specify a default. Up to you.\n    formatter = formatter ?? Formatter<DataField>.Default;\n\n    foreach (DataField field in m_fields)\n    {\n        Console.WriteLine(formatter.Format(field));\n    }\n}\n

\n\n

然后，它不再StringUtils是一个静态实用程序类，而只是一个类的一个实现，该类提供了一种格式化某种类型对象的方法（在您的例子中，是string对象；在我的示例中，这些想象的对象）DataField对象）。

\n\n

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

\n\n

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

\n