By

前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

image-20210706205043822

一、单一职责

1、解释：

官方定义：

就一个类(接口、结构体、方法等等)而言，有且仅有一个引起它变化的原因。

个人理解：

通俗的来讲做一件事就是专注做一件事，不可以三心二意。任务对象只是专注于一项职责，不去承担太多的责任。当任务对象的职责发生变化时，不会对其他的对象产生影响。

​

2、应用

背景：有一个类A，他需要负责 T1 和T2。但是当职责 T1 因为需求而改变类 A 的时候，就会对职责 T2 造成影响，导致 T2 不能正常工作。

解决办法：针对职责 T1 创建类 A ，针对职责 T2 创建类 B 。这样就可以达到当修改类 A 时不会对职责 T2 造成影响，当修改类 B时不会对职责T1造成影响。

二、里氏替换原则

1、解释：

官方定义：里氏代换原则 (Liskov Substitution Principle LSP) 面向对象设计的基本原则之一。

⬤ 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。

⬤ LSP 是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

个人理解：子类可以扩展父类的功能，但不能改变父类原有的功能，子类中尽量不要去重写父类方法，A类的所有方法都被B类重写了。 那何必继承呢？直接新建一个B类不就好了，采用final 的手段强制来遵循

⬤ 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

⬤ 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

⬤ 子类中可以增加自己特有的方法。

⬤ 当子类的方法重载父类的方法时，方法的前置条件要比父类方法的输入参数更宽松。

⬤ 子类的方法实现父类的抽象方法时，方法的返回值要比父类的返回值更加严谨。

2、应用

经典案例之正方形不是长方形：

1）反例

a、Rectangle 类

@Data
@AllArgsConstructor
public class Rectangle {

	private int width;
	private int height;

	public int area() {
		return width * height;
	}

}

b、Square 类


@Data
@AllArgsConstructor
public class Square extends Rectangle {

	public int area() {
		return width * width;
	}
}

c、Tester 类


public class Tester {

  public static void main(String[] args) {
    Rectangle rectangle = new Rectangle(10, 20);
    System.out.println("面积：" + rectangle.area());
    // 输出结果为面积：200

    Square rectangle = new Square(10, 20);
    System.out.println("面积：" + rectangle.area());
    // 输出结果为面积：0
  }
}

2）分析总结

问题1：：为什么当 Rectangle替换为Square之后，面积的结果出错了呢？

答案：因为在Square类里重写了area()方法，很明显违背了里氏替换原则，改变了父类的原有功能，所以导致输出结果不对。

三、依赖倒置原则

1、解释

所谓依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体，依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。

实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段。

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

通俗点说：要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

依赖倒置需遵循规则：

⬤ 低层模块尽量都要有抽象类或接口，或者两者都有。【可能会被人用到的】

⬤ 变量的声明类型尽量是抽象类或接口。

⬤ 使用继承时遵循里氏替换原则。

2、反例：

反例：类 A 直接依赖类 B ，假如要将类 A 改为依赖类 C ，则必须通过修改类 A 的代码来达成。 这种场景下，类 A 一般是高层模块，负责复杂的业务逻辑；类 B 和类 C 是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类 A 修改为依赖接口I，类B和类C各自实现接口 I ，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

class Book{
    public String getContent(){
        return "很久很久以前有一个阿拉伯的故事……";
    }
}

class Mother{
    public void narrate(Book book){
        System.out.println("妈妈开始讲故事");
        System.out.println(book.getContent());
    }
}

public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
    }
}

代码解释：上述是面向实现的编程，即依赖的是Book这个具体的实现类；看起来功能都很OK，也没有什么问题。运行良好

问题1：假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码如下：

class Newspaper{
    public String getContent(){
        return "林书豪38+7领导尼克斯击败湖人……";
    }
}

这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，居然必须要修改Mother才能读。假如以后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行

3、正例

所以：我们引入一个抽象的接口IReader。读物，只要是带字的都属于读物：

class Newspaper implements IReader {
    public String getContent(){
        return "林书豪17+9助尼克斯击败老鹰……";
    }
}
class Book implements IReader{
    public String getContent(){
        return "很久很久以前有一个阿拉伯的故事……";
    }
}

class Mother{
    public void narrate(IReader reader){
        System.out.println("妈妈开始讲故事");
        System.out.println(reader.getContent());
    }
}

public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
        mother.narrate(new Newspaper());
    }
}

四、接口隔离原则

1、解释：

原定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上，。

问题由来：类 A 通过接口 I 依赖类 B ，类 C 通过接口 I 依赖类 D ，如果接口 I 对于类 A 和类 B 来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

**解决方案：将臃肿的接口 I 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。 **

建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少

⬤ 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。

⬤ 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

⬤ 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

2、反例

下图具体来说：

1、类 A 依赖接口 I 中的方法1、方法2、方法3，类 B 是对类 A 依赖的实现。

2、类 C 依赖接口 I 中的方法 1、方法4、方法5，类 D 是对类 C 依赖的实现。

3、对于类 B 和类 D 来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。对类图不熟悉的可以参照程序代码来理解，代码如下：

image-20210708150714893

interface I {
    public void method1();
    public void method2();
    public void method3();
    public void method4();
    public void method5();
}

class A{
    public void depend1(I i){
        i.method1();
    }
    public void depend2(I i){
        i.method2();
    }
    public void depend3(I i){
        i.method3();
    }
}

class B implements I{
    public void method1() {
        System.out.println("类B实现接口I的方法1");
    }
    public void method2() {
        System.out.println("类B实现接口I的方法2");
    }
    public void method3() {
        System.out.println("类B实现接口I的方法3");
    }
    //对于类B来说，method4和method5不是必需的，但是由于接口A中有这两个方法，
    //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
    public void method4() {}
    public void method5() {}
}

class C{
    public void depend1(I i){
        i.method1();
    }
    public void depend2(I i){
        i.method4();
    }
    public void depend3(I i){
        i.method5();
    }
}

class D implements I{
    public void method1() {
        System.out.println("类D实现接口I的方法1");
    }
    //对于类D来说，method2和method3不是必需的，但是由于接口A中有这两个方法，
    //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
    public void method2() {}
    public void method3() {}

    public void method4() {
        System.out.println("类D实现接口I的方法4");
    }
    public void method5() {
        System.out.println("类D实现接口I的方法5");
    }
}

public class Client{
    public static void main(String[] args){
        A a = new A();
        a.depend1(new B());
        a.depend2(new B());
        a.depend3(new B());
        
        C c = new C();
        c.depend1(new D());
        c.depend2(new D());
        c.depend3(new D());
    }
}

3、正例

如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口。

image-20210708151511003

interface I1 {
    public void method1();
}

interface I2 {
    public void method2();
    public void method3();
}

interface I3 {
    public void method4();
    public void method5();
}

class A{
    public void depend1(I1 i){
        i.method1();
    }
    public void depend2(I2 i){
        i.method2();
    }
    public void depend3(I2 i){
        i.method3();
    }
}

class B implements I1, I2{
    public void method1() {
        System.out.println("类B实现接口I1的方法1");
    }
    public void method2() {
        System.out.println("类B实现接口I2的方法2");
    }
    public void method3() {
        System.out.println("类B实现接口I2的方法3");
    }
}

class C{
    public void depend1(I1 i){
        i.method1();
    }
    public void depend2(I3 i){
        i.method4();
    }
    public void depend3(I3 i){
        i.method5();
    }
}

class D implements I1, I3{
    public void method1() {
        System.out.println("类D实现接口I1的方法1");
    }
    public void method4() {
        System.out.println("类D实现接口I3的方法4");
    }
    public void method5() {
        System.out.println("类D实现接口I3的方法5");
    }
}

五、迪米特法则（最少知道原则）

1、解释

为什么叫最少知道原则：

就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。

定义：一个对象应该对其他对象保持最少的了解。

**通俗的来讲：就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。 **

问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

解决方案：尽量降低类与类之间的耦合。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。

1、单个方法尽量不引入一个类中不存在的对象

2、尽量不要公布太多的 public 方法和非静态的 public 变量

3、如果一个方法放在本类中，既不增加类间的关系，也对本类不产生负面影响，那就放置在本类中

2、反例

举一个例子：有一个集团公司，下属单位有分公司和直属部门，现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

反例原因：现在这个设计的主要问题出 在 CompanyManager中，根据迪米特法则，只与直接的朋友发生通信，而 SubEmployee 类并不是 CompanyManager 类的直接朋友（以局部变量出现的耦合不属于直接朋友），从逻辑上讲总公司只与他的分公司耦合就行了，与分公司的员工并没有任何联系，这样设计显然是增加了不必要的耦合。

//总公司员工
class Employee{
  private String id;
  public void setId(String id){
    this.id = id;
  }
  public String getId(){
    return id;
  }
}

//分公司员工
class SubEmployee{
  private String id;
  public void setId(String id){
    this.id = id;
  }
  public String getId(){
    return id;
  }
}

class SubCompanyManager{
  public List<SubEmployee> getAllEmployee(){
    List<SubEmployee> list = new ArrayList<SubEmployee>();
    for(int i=0; i<100; i++){
      SubEmployee emp = new SubEmployee();
      //为分公司人员按顺序分配一个ID
      emp.setId("分公司"+i);
      list.add(emp);
    }
    return list;
  }
}

class CompanyManager{

  public List<Employee> getAllEmployee(){
    List<Employee> list = new ArrayList<Employee>();
    for(int i=0; i<30; i++){
      Employee emp = new Employee();
      //为总公司人员按顺序分配一个ID
      emp.setId("总公司"+i);
      list.add(emp);
    }
    return list;
  }

  public void printAllEmployee(SubCompanyManager sub){
    List<SubEmployee> list1 = sub.getAllEmployee();
    for(SubEmployee e:list1){
      System.out.println(e.getId());
    }

    List<Employee> list2 = this.getAllEmployee();
    for(Employee e:list2){
      System.out.println(e.getId());
    }
  }
}

public class Client{
  public static void main(String[] args){
    CompanyManager e = new CompanyManager();
    e.printAllEmployee(new SubCompanyManager());
  }
}

3、正例

按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。修改后，为分公司增加了打印人员 ID 的方法，总公司直接调用来打印，从而避免了与分公司的员工发生耦合。

class SubCompanyManager{
    public List<SubEmployee> getAllEmployee(){
        List<SubEmployee> list = new ArrayList<SubEmployee>();
        for(int i=0; i<100; i++){
            SubEmployee emp = new SubEmployee();
            //为分公司人员按顺序分配一个ID
            emp.setId("分公司"+i);
            list.add(emp);
        }
        return list;
    }
    public void printEmployee(){
        List<SubEmployee> list = this.getAllEmployee();
        for(SubEmployee e:list){
            System.out.println(e.getId());
        }
    }
}

class CompanyManager{
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<Employee>();
        for(int i=0; i<30; i++){
            Employee emp = new Employee();
            //为总公司人员按顺序分配一个ID
            emp.setId("总公司"+i);
            list.add(emp);
        }
        return list;
    }
    
    public void printAllEmployee(SubCompanyManager sub){
        sub.printEmployee();
        List<Employee> list2 = this.getAllEmployee();
        for(Employee e:list2){
            System.out.println(e.getId());
        }
    }
}

六、开闭原则

1、解释

解释：开闭原则就是说对扩展开放，对修改关闭。

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

ContactAuthor