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

时间:2010-01-29 22:20:36

标签: language-agnostic static-methods

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

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

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

HFile.save('filename')

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

6 个答案:

答案 0 :(得分:11)

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

答案 1 :(得分:6)

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

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

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

答案 2 :(得分:5)

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

答案 3 :(得分:3)

我不会担心静态方法的数量,就像我对这些方法正在做什么一样。一个静态方法,它返回一个值,或者修改一个作为参数传递的对象?没什么大不了。一个修改私有静态字段的静态方法?我担心。一种静态方法,修改属于其他类的公共静态字段?我需要躺在黑暗的房间里,眉毛上有一块湿毛巾。

答案 4 :(得分:2)

这不是面向对象的,是吗?现在也许你的地方并不喜欢OO代码,那很好。但是如果你想封装数据和方法,那么你需要实例方法来处理这些数据。

大量的静态方法可能与许多全局变量有关。例如。如果您要调用静态HFile.save('filename'),那么您尝试保存到文件名中的信息必须是全局的。通常我们会尝试减少全局变量以使事情更易于管理。

但是如果你想编写程序代码,那就没关系。

答案 5 :(得分:2)

IMO静态方法对于您所描述的目的在您的工作场所很常见。 这种方法的缺点:
- 创建一个表示文件的对象的重点是什么,只是为了调用它上面的一个方法?
- 不能使用基于接口的多态性

要回答你的问题,这里有一些我会使用静态方法的情况:
- 一种实用程序方法,它执行与类的功能相关的操作,但不执行任何一个对象。也许它需要一组对象并对它们进行比较。也许它会进行一些通用的数据操作(转换等) - 你需要用类变量做类相关的东西 - 您想要实现单件设计模式的地方