设计原则之单一职责原则

Java是一门面向对象编程的语言，但在实际开发中，我们实际更多的应该是面向接口编程，而对于我们设计的接口或者类来说，功能应该尽可能的单一，而不是大而全的胖接口。
例如我们在设计一个汽车类的时候，会首先定义一个汽车的接口：

public interface ICar {

    /**
     * 获取座位数量
     * @return
     */
    int getSeatsCount();

    /**
     * 获取汽车的车牌号
     * @return
     */
    String getNumberPlate();

    /**
     * 喇叭
     */
    void speaker();

    /**
     * 汽车开动
     */
    void drive();

}

与之对应的汽车类图

这个接口初看其实没什么问题，都是设计一个汽车应该具备的，但是你如果自己观察会发现，这个汽车接口的功能和属性没有分离，即车牌号，座位数应该属于汽车的属性，而喇叭，开动汽车这些应该是属于功能模块。

对上述类图进行修改：

重新拆分成两个接口，一个负责属性，一个负责功能。此时实现类里面实现了两个接口，把两个职责融合到一个类中

小结：

1.类的复杂性降低，实现的职责都有明确的定义。
2.可读性提高
3.可维护性提高，变更的风险更小，一个职责对应的接口修改只会影响自身，对其他的接口不会有影响。

但是单一职责比较麻烦的一点就是没有一个具体的量化标准去划分职责，理论上将一个职责应该对应一个接口，至于如何细化还需要从实际的项目中去考虑。