设计模式：单一职责原则

官方定义

单一职责原则（Single Responsibility Principe SRP）有且仅有一个原因引起类的变更

顾名思义：一个类只负责一项职责

基本介绍

即对类来说，一个类应该值负责一项职责。如果类A负责两个不同职责：职责1，职责2，当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的力度分解为A1，A2

案例：动物世界

需求：有一个动物类，里面定义了一个在深林奔跑的方法，创建动物的实例，调用方法，方法内执行打印操作

public class SingleDemo{
    
   public static void main(String[] args){
       new Animal().run("老虎");
       new Animal().run("狮子");
       new Animal().run("老鹰");
   }
}

class Animal{
    //森林奔跑的方法
    public void run(String aniaml){
        System.out.println(animal+"在森林里愉快的奔跑");
    }
}

很明显老鹰在森林里愉快的奔跑是比较奇怪的

解决方案一

拆分类、拆分类为更小的粒度

public class SingleDemo{
    public static void main(String[] args){
        new ForestAnimal().run("老虎"); 
        new ForestAnimal().run("狮子"); 
        new ForestAnimal().run("老狼"); 
        new AirAnimal().fly("老鹰");
    }
}

class ForestAnimal{
    public void run(String animal){
        System.out.println(animal + "在森林里愉快的奔跑");
    }
}

class AirAnimal{
    public void fly(String animal){
        System.out.println(animal + "在天空愉快的飞翔");
    }
}

方案一分析

优势：符合了业务逻辑，符合了单一职责原则

劣势：改动幅度大，不光拆分类，客户端的代码也要进行大幅度的改动

解决方案二

直接在原来的类的基础上进行改动

public class SingleDemo{
    
   public static void main(String[] args){
       new Animal().run("老虎");
       new Animal().run("狮子");
       new Animal().fly("老鹰");
   }
}

class Animal{
    //森林奔跑的方法
    public void run(String aniaml){
        System.out.println(animal+"在森林里愉快的奔跑");
    }
    //天空飞翔的方法
     public void fly(String animal){
        System.out.println(animal + "在天空愉快的飞翔");
    }   
    
}

方案二分析

优势：改动幅度小，包括客户端，完成了业务逻辑

劣势：是否违反了单一职责原则？（方法级别的遵守）

单一职责原则：各司其职

通过上面两种，大家可以看到，方案一，类级别遵守了单一职责原则，但是改动的带价很大

方案二，方法级别遵守了单一职责原则，改动幅度较小

综上所述，单一职责原则最核心的是什么？ 各司其职

注意事项&细节

• 降低类的复杂度，一个类只负责一项职责
  • 一个类职责少了，相应的负责度不就低了嘛
• 提高类的可读性已经可维护性
  • 相应的复杂度降低了，代码量就会减少，可读性也就提高了，可维护性自然也就提高了
• 降低变更引起的风险
  • 一个类的职责越多，变更的可能性就越大，变化带来的风险也就会越大
• 通常情况下，我们应当遵守类级别单一职责原则
  • 只有逻辑足够简单，才可以在代码中违反单一职责原则

如何遵守单一职责原则

其实就是合理的职责分解

从业务出发，从需求出发，识别出同一个类型的职责

需要说明一点，单一职责原则不是面向对象语言特有的，只有是模块化的程序设计，都要遵守单一职责原则。