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