我们目前有一个实用程序类，可以处理大量字符串格式、日期显示和类似功能，它是一个共享/静态类。
这是“正确”的做事方式，还是我们应该在需要时实例化实用程序类？
我们的主要目标是减少内存占用，但应用程序的性能也是一个考虑因素。
PS。我们正在使用 .NET 2.0
【问题讨论】：
标签： oop
这是“正确”的做事方式，还是我们应该在需要时实例化实用程序类？
从OOD的角度来看，这取决于:-)
对于pure functions，您应该在Java/C# 中使用静态方法。在 C# 中，您也可以尝试使用其他人描述的扩展方法。
对于不是纯函数的实用方法（例如读取某个文件），您应该创建一个实例来提高可测试性（例如允许模拟）。
不同之处在于后者虽然不直接保持任何状态，但它们与一些具有自己的、可能改变状态的外部组件通信。这种外部状态可能会导致此实用程序方法随着时间的推移（对于相同的输入）返回不同的结果，从而使其更难测试和推理。通过将后者作为显式实例方法来区分纯函数和此类实用方法是一个很好的设计原则。
然而，在 Java 实践中，“模拟参数”通常需要前置，因为它不允许模拟静态方法。
【讨论】：
如果类中有任何状态，那么最好从它中创建对象。就对象依赖和线程安全而言，单例是一种痛苦。
如果类中没有状态，那么选择是否将其设为静态对内存占用没有明显影响。
【讨论】：
如果您使用的是 .NET，您是否考虑过使用扩展方法？我发现如果使用得当，我什至可能根本不需要实用程序类。
【讨论】：
这是在 .NET 中吗？如果是这样，最好提供扩展方法。例如。如果您有一个格式化字符串的实用程序方法，请将其签名从
public static string SpecialFormat(string text)
到
public static string SpecialFormat(this string text)
这样，SpecialFormat 方法将更容易被发现，因为它将作为字符串上的方法出现。
【讨论】：
如果您的语言支持，请将这些函数作为包/命名空间/模块的一部分，而不是类。
如果没有，类的静态方法就可以了。如果您的语言支持，您应该将类标记为 final/closed/nonvirtual/non-extendable。
如果您的语言支持，您可以考虑为这些函数接受的类型重新定义内置类/定义，但要小心命名空间冲突。在这种情况下，请按照您选择的语言的样式指南或事实标准来选择惯用方法。
【讨论】：
静态类适用于您所描述的内容 - 请注意任何共享状态（静态成员变量）都以线程安全的方式共享。
【讨论】：