【设计模式学习】（二）七大原则之单一职责原则

理论知识

---

概念

一个类或模块只负责一个职责 (职责: 指引起变化的原因)

不遵循单一职责原则的缺点

1. 一个类或模块负责多个职责, 使一个类变的极为复杂
2. 引起变化的原因过多，发生错误时不易定位
3. 使用一个类必须加载它的所有职责，包括不需要的职责，造成代码的冗余
4. 当修改一个类的职责时，可能影响到类的其他职责

单一职责优点

1. 降低代码的复杂度
2. 提升代码可读性
3. 提升代码复用性
4. 降低系统的维护成本
5. 减少修改职责可能带来的风险

代码实现

---

不遵循单一职责

package com.study.singleResponsibilty;

public class SingleResponsibility1 {
    public static void main(String[] args) {
        // 类实例化
        Vehicle v1 = new Vehicle("汽车");
        Vehicle v2 = new Vehicle("飞机");
        Vehicle v3 = new Vehicle("轮船");

        // 调用行驶方法
        v1.mov();
        v2.mov();
        v3.mov();
    }
}

// 交通工具类
class Vehicle{
    private final String vehicleType ;

    // 构造方法
    public Vehicle(String vehicleType) {
        this.vehicleType = vehicleType;
    }

    //方法: 行驶
    public void mov(){
        System.out.println(this.vehicleType + "在马路上行驶");
    }
}

交通工具类都调用行驶方法，明显，轮船和飞机不太合适

严格遵循单一职责原则

package com.study.singleResponsibilty;

public class SingleResponsibility3 {
    public static void main(String[] args) {
        // 类实例化
        RoadVehicle rv = new RoadVehicle("汽车");
        AirVehicle av = new AirVehicle("飞机");
        SeaVehicle sv = new SeaVehicle("轮船");

        // 调用方法
        rv.mov();
        av.mov();
        sv.mov();
    }
}

// 陆地交通工具类
class RoadVehicle {
    private final String vehicleType;

    // 构造方法
    public RoadVehicle(String vehicleType) {
        this.vehicleType = vehicleType;
    }

    // 方法: 行驶
    public void mov(){
        System.out.println(this.vehicleType + "在公路行驶");
    }
}

// 空中交通工具类
class AirVehicle {
    private final String vehicleType;

    // 构造方法
    public AirVehicle(String vehicleType) {
        this.vehicleType = vehicleType;
    }

    // 方法: 行驶
    public void mov(){
        System.out.println(this.vehicleType + "在空中行驶");
    }
}


// 海上交通工具类
class SeaVehicle {
    private final String vehicleType;

    // 构造方法
    public SeaVehicle(String vehicleType) {
        this.vehicleType = vehicleType;
    }

    // 方法: 行驶
    public void mov(){
        System.out.println(this.vehicleType + "在海上行驶");
    }
}

严格遵循了单一职责原则，一个类只负责一种职责，但是浪费了很多的资源，且三个类明显有极其相似的特征，可以整合到一起

方法层面遵循单一职责原则

package com.study.singleResponsibilty;

public class SingleResponsibility2 {
    public static void main(String[] args) {
        // 类实例化
        Vehicle1 v1 = new Vehicle1("汽车");
        Vehicle1 v2 = new Vehicle1("飞机");
        Vehicle1 v3 = new Vehicle1("轮船");

        // 调用方法
        v1.RoadMov();
        v2.AirMov();
        v3.SeaMov();
    }
}

// 交通工具类
class Vehicle1 {
    private final String VehicleType;

    // 构造方法
    public Vehicle1(String vehicleType) {
        this.VehicleType = vehicleType;
    }

    // 方法: 公路行驶
    public void RoadMov(){
        System.out.println(this.VehicleType + "在公路行驶");
    }

    // 方法: 空中行驶
    public void AirMov(){
        System.out.println(this.VehicleType + "在天空行驶");
    }

    // 方法: 海上行驶
    public void SeaMov(){
        System.out.println(this.VehicleType + "在海上行驶");
    }
}

虽然没有严格遵循单一职责原则，但在方法层面上同样体现了单一职责的思想，且很好的解决了问题，同时，避免了资源的大量浪费

总结思考

---

如何理解 “职责: 发生变化的原因”？

引起类发生变化的原因，即类所负责的事情。
例如，手机可以用来打电话，也可以用玩游戏。打电话和玩游戏便是两种“发生变化的原因”，这时单一职责原则要求分成两个类。

“单一” 的边界

一个类怎样才足够“单一”， 是没有绝对的、可量化的指标的。类的单一程度，应该取决于业务需求。
例如，一个系统有用户功能和订单功能，此时可以分为用户信息类和订单信息类，但是订单类需要用到用户地址等信息，所以就需要从用户信息类中分解出一个用户地址信息类。

越“单一”一定越好吗？

很明显，“单一”是需要适度的，拆分的过于细，反而可能导致内聚性降低，使代码难以维护。