最近项目中使用Spring Boot,让我稍微有些水土不服,主要原因就是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的非静态类实例,而我们都知道,在静态方法里面是无法使用非静态变量的。如果要使用这些注入的对象,最简单的方式就是把使用的这些方法都写成非静态的。这多少让我有些不适应,特别是如果这个方法是无状态的,甚至它只是个偏工具的方法或者类。直觉告诉我,对于一个成熟的东西,如果你用着别扭,那很大可能是因为你的用法不对。于是我尝试着Goole了一下,发现和我有同样问题的人还不在少数,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)服你的话,可以看一下下面的几篇文章,我觉得非常不错: