OOP中static的原罪
风格1：
@Autowired MyService myservice; // doSomething是MyService类的非静态方法 Response resp = myservice.doSomething(someParameters);
风格2：
// doSomething是MyService类的静态方法 Response resp = MyService.doSomething(someParameters);
你平时Coding喜欢哪一种？对我而言，如果 doSomething
是无状态的，我一般都是使用第二种。更广一点，对于任何无状态的，我一般都喜欢写成static的。主要原因是调用起来方便，使用者不需要创建实例即可使用。而且一般静态调用会比实例调用快一些，因为没有实例创建、初始化的动作。但在使用Spring时，这种习惯让我举步维艰。因为Spring的核心技术之一就是 依赖注入（Dependency Injection，DI）
，注入的变量其实都是各个Bean的非静态类实例。而我们都知道，在静态方法里面是无法使用非静态变量的。如果要使用这些注入的对象，最简单的方式就是把静态方法改成非静态的。这多少让我有些不适应，特别是如果这个方法是无状态的，甚至它只是个偏工具的方法或者类。直觉告诉我，对于一个成熟的东西，如果你用着别扭，那很大可能是因为你的用法不对。于是我尝试着Google了一下，发现和我有同样问题的人还不在少数，Stack Overflow上面也有许多牛人给出了workaround，但终归只是workaround，还是让人觉得用着变扭。再深究，发现其实在OOP里面就不应该用static，至少要少用、慎用。这便是 static的原罪：使用static方法这种编程属于procedural programming（面向过程的程序设计），而不是OOP。
先来看个例子，假设我们有一个 Person
类和一个 PersonApp
类如下：
@Getter
@Setter
public class Person {
private int id;
private String firstName;
private String lastName;
public static Person createNew() {
Person temp = new Person();
temp.id = -1;
temp.firstName = "";
temp.lastName = "";
return temp;
}
@Override
public String toString() {
return "Person{" +
"id=" + id +
", firstName='" + firstName + '\'' +
", lastName='" + lastName + '\'' +
'}';
}
}
public class PersonApp {
public void doSomething() {
// 调用静态方法createNew()
Person person = Person.createNew();
person.setId(1);
person.setFirstName("Yanchun");
person.setLastName("Ni");
// 调用实例方法toString()
System.out.println(person.toString());
}
}
目前来看， PersonApp
可以很方便的使用 Person
中的方法，不论是静态方法 createNew()
还是非静态方法 toString()
。但随着业务发展呢，我们又接到一个新的需求，需要增加一个员工类 Employee
，并且是从 Person
继承来的。然后我们定义了如下员工类：
@Getter
@Setter
public class Employee extends Person {
private String boss;
private String department;
@Override
public String toString() {
return "Employee{" +
"boss='" + boss + '\'' +
", department='" + department + '\'' +
", FirstName()='" + super.getFirstName() + '\'' +
", FirstName()='" + super.getLastName() + '\'' +
'}';
}
}
可以看到，对于非静态的 toString()
方法，我们可以通过覆写父类的 toString()
来实现自己的 toString()
。和Person类一样，我们也需要提供一个 createNew()
来创建Employee实例，但遗憾的是我们无法覆盖一个静态方法，只能重新写一个 createNew()
。显然覆盖写是OOP中的编程思想，而重新写一个是面向过程里面的思想。这只是一个继承的例子。OOP中还有很多技术都依赖类实例实现，比如多态、注入、基于接口的编程（interface-driven）、基于代理的AOP等。而DI、AOP都是Spring使用的核心技术，我喜欢用static的风格自然会让我在使用Spring的时候各种水土不服。
这里只是用Java举了一个例子，文末我会附几个链接，都是说明为什么不应该在OOP里面使用静态方法的原因，有基于PHP的，有基于C#的，也有基于Java的，作者们的核心观点总结起来有两方面，一方面就是静态方法属于面向过程语言的思想，用在OOP里面会让很多OOP技术都不可用，比如上面的例子就属于这种，静态方法让程序丧失了可扩展性。另一方面就是不利于自动化的单元测试，因为单元测试是要将代码功能块隔离开测试，而代码之间都是有依赖的，如果是基于实例的，我们可以使用Mock等技术创造一些假的依赖类的实例，但如果实现为静态方法，那这种技术也就无能为力了，所以静态方法也是单元测试的噩梦。更有激进的作者认为，像 Math.abs(-5)
这种标准库的实现是因为语言设计的不对（比如Java），正确设计应该是 -5.abs()
，比如Ruby就是这样设计的。
本文写的比较简单，结论就是： 在OOP中，慎用静态方法
。如果还不足以说( shuo
，这个不读 shui
)服你的话，可以看一下下面的几篇文章，我觉得非常不错：
-
10 Golden Rules Of Good OOP
(第5条： Avoid Static Classes for Helpers, Utilities & C.
) - Static methods are a code smell
- Avoid Utility Classes
- Why Static is Bad and How to Avoid It
- Static Methods are Death to Testability
About The Author
