避免静态方法过度使用的提示

Question

我正在重构一些代码,我正在看一个名为HFile的类.HFile具有所有私有构造函数,因此您无法实际创建它的实例.而不是如下创建HFiles的实例:

var file = new HFile('filename')
file.Save()

所有HFile交互都是通过静态方法处理的.所以,如果我想保存文件,我会打电话:

HFile.save('filename')

然后在内部创建一个HFile实例然后保存.显然,在不了解整个故事的情况下,任何读者都必须保留判断力,但似乎使用静态方法在我的工作场所变得非常流行.所以我想知道静态方法的使用是否有良好的原则/最佳实践,可以帮助一群人坐下来回顾他们对静态方法的使用.

Answer 1

许多静态方法/静态类是程序性的症状 - 用面向对象的语言编写过程代码.我所知道的消除这种思维的最好方法是彻底理解面向对象的原则和实践.使用测试驱动的开发并强制代码可测试将有所帮助,因为编写静态类的测试要困难得多.最终,如果你使用TDD,你自然会倾向于更加分离的OO架构,如果只是为了减轻测试的痛苦.

Answer 2

通常,如果您的情况需要封装状态或组织结构,那么您将使用类.

另一方面,如果您有一些跨领域的问题,并且可以在您的应用程序中广泛使用,那么您可以考虑静态实用程序类中的方法. System.Math在.NET框架(和Java)中就是一个例子.

在你的例子中,HFile可能是一个有状态的对象,所以我通常不会使用静态方法来保存它.只是对特定的HFile对象进行方法调用更简单,而不是必须将整个对象传递给静态方法进行保存.在您的特定应用程序中是否有意义取决于您的应用程序的范例是将HFile对象视为要通过外部方法传递和执行的事物,还是作为能够自我保存的独立对象.

Answer 3

静态方法很难测试,因为你无法模拟它们.出于这个原因,我们倾向于在我的工作地点避开它们.虽然我们确实将它们用于工厂方法.