为什么应该少用静态（static）方法：静态方法的三大问题

背景

静态方法非常常见，比如很多工具类中都会有大量静态方法。

之前我对这种现象习以为常，直到最近发生的几件事让我决定以后要尽量避免用静态方法。

下面就来看看静态方法的三大问题。

（这里以 Java 为例，但相信很多语言应该都一样。）

静态方法的三大问题

问题 1：测试困难

相比常规方法，在 Java 中对静态方法进行 mock 要复杂一些。Mockito 直到 3.4.0 版本才支持 mock 静态方法。

不过，这实在是三个问题里最轻的一个了。

问题 2：不灵活

面向对象语言的精髓就是依赖抽象，而不是依赖实现。在 Java 中，可以通过接口或者抽象类来实现这一点。

而静态方法则不具备这一灵活性。比如，组件 A 调用了组件 B 的静态方法 staticMethodFromB，那么当需求发生调整，需要调用组件 C 的静态方法 staticMethodFromC 来替换 staticMethodFromB 的时候，组件 A 也必须调整。

如果只是一个组件 A 来调用，那倒还好，如果是几十上百个组件都需要切换呢？那就非常头疼了。对于普通方法我们可以使用依赖注入的方式实现统一替换，但这不适用于静态方法。

问题 3：静态传染

如果一个普通方法 methodA 需要调用另一个方法 methodB，那么 methodB 可以是普通方法或者静态方法；

如果一个静态方法 staticMethodA 需要调用另一个方法 methodB，那么 methodB 也必须是静态的。

这就导致，你引入了一个静态方法，可能就意味着出现越来越多静态方法。。

最近就碰到了一件这样的事：有个类 SomeClass 里几乎全是静态方法，可是忽然要加一个功能，这个功能需要注入一个对象，所以不能以静态方式完成了。。于是几乎需要把 SomeClass 里所有方法都从静态改成普通，以及修改所有调用者。。这是一个非常耗时且容易出错的过程！

所以这里奉劝大家，用静态方法真的要慎重！！

小结

我现在觉得，只有在完全完全确定一个方法不会有结构调整，与系统中其他部分几乎没有关联时，才可以考虑把它写成静态方法。

否则，不要用静态方法！