设计模式的七大设计原则

为什么要学习设计原则

七大设计原则的目的都是为了设计出稳定的代码结构，以后如果要新增业务时，让我们可以不去改动之前稳定的代码，简单的新增代码就可以了，修改底层代码那可能会带来意想不到的风险（频繁的毫无章法的修改代码很容易导致之前的代码也不能用或者执行结果改变），但是我们也不是说任何时候都要去追求符合七大设计原则，（我们得考虑人力，时间，成本，质量等等因素）而是在适当的场景遵循设计原则。跟数据结构的时空思想类似，是一种平衡取舍的思想。

废话少说，先上图（不理解就继续往下看）

1.开闭原则（使用最广）

概念：开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放， 对修改关闭。

解释
其实就是说如果当前的业务功能需要扩展，那么尽量不要去改动之前的代码。而是通过新建类来实现业务的扩展

例子（建议大家把代码弄到编译器里面去或者画个图，不然不好理解）
ICourse是一个接口，意义代表课程，但不具体。

public interface ICourse
 { 
 Integer getId();
 //得到课程的名字
  String getName(); 
  //得到课程的价格
  Double getPrice();
   }

JavaCourse实现了ICourse，是一个具体的课程即java课程

public class JavaCourse implements ICourse{
    private Integer id;
    private String name;
    private Double price;

    public JavaCourse(Integer id, String name, Double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }

    public Integer getId() {
        return this.id;
    }

    public String getName() {
        return this.name;
    }

    public Double getPrice() {
        return this.price;
    }
}

现在我们要给 Java 课程做活动，价格优惠。如果修改 JavaCourse 中的 getPrice()方法，则会 存在一定的风险，可能影响其他地方的调用结果（比如卖java课程得有几个商家，其中一些打折，一些不打折）。我们如何在不修改原有代码前提前下，实现价格优惠 这个功能呢？

刚才的解释已经说了，通过新建类来实现业务的扩展，我们新建一个JavaDiscountCourse 类

public class JavaDiscountCourse extends JavaCourse {
    public JavaDiscountCourse(Integer id, String name, Double price) {
        super(id, name, price);
    }

    //请注意这个方法最好是新增的方法，不要去重写父类的getPrice方法
    //因为如果重写了，如果需要查看原价就不行了！
    public Double getDiscountPrice(){
        return super.getPrice() * 0.6;
    }

}

这样我们就可以只针对需要打折的地方使用JavaDiscountCourse 类就可以了，而不会影响不想打折的那些地方

类图

优点：能提高软件系统的可维护性

2.依赖倒置原则

概念：依赖倒置原则（Dependence Inversion Principle,DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖抽象。

解释
针对接口编程，不针对实现编程，减少类与类之间的耦合性（使用多态进行传参）

注意
以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家在拿到需求之后， 要面向接口编程，先顶层再细节来设计代码结构。
先设计好顶层接口，再来具体实现，这种思想用的非常多

例子

public class Tom { 

public void studyJavaCourse()
{ 
System.out.println("Tom 在学习 Java 的课程");
 }
 
 public void studyPythonCourse()
 { 
 System.out.println("Tom 在学习 Python 的课程"); 
 } 
 
 }

Tom 爱学习，目前正在学习 Java 课程和 Python 课程。随着学习兴趣的暴涨，现在 Tom 还想学习 AI 人工智能的课程。这个时候，业务扩展，我们的代码要从底层（实体层） 到高层（调用层）一次修改代码。在 Tom 类中增加 studyAICourse()的方法，在高层也要追加调用。这时明显就违背了设计原则的目的

解决办法
同样建一个ICourse接口（顶层接口）

public interface ICourse 
{ 
void study(); 
}

建一个JavaCourse类实现了ICourse接口

public class JavaCourse implements ICourse 
{ 
      @Override 
      public void study() 
      { 
      System.out.println("Tom 在学习 Java 课程"); 
      } 
 }

建一个PythonCourse类实现了ICourse接口

public class PythonCourse implements ICourse
 { 
 
 @Override 
 public void study() 
 { 
 System.out.println("Tom 在学习 Python 课程"); 
 } 
 
}

修改Tom类

public class Tom { 

public void study(ICourse course)
{ 
course.study();
 }
 
  }
  

调用类

public static void main(String[] args) { 
Tom tom = new Tom();
 tom.study(new JavaCourse());
  tom.study(new PythonCourse()); 
  }

这时的代码结构的好处就是Tom 的兴趣无论怎么暴涨，对于新的课程，我只需要新建一个类，通过传参的方式告诉 Tom，而不需要修改底层代码。（这其实就是Spring的依赖注入方式）

注入的方式还有构造器方式和 setter 方式。我们来看构造器注入方式：

public class Tom { 

private ICourse course;

public Tom(ICourse course)
{ 
this.course = course; 
}

public void study()
{ 
course.study(); 
} 

}

根据构造器方式注入，在调用时，每次都要创建实例。那么，如果 Tom 是全局单例，则我们就只能 选择用 Setter 方式来注入，继续修改 Tom 类的代码：

public class Tom { 

private ICourse course; 

public void setCourse(ICourse course) 
{ 
this.course = course;
 }
 
 public void study()
 { 
 course.study();
  } 
  
  }

改进
上述代码其实还可以继续改进，把PythonCourse和JavaCourse类的study方法不要打印名字，修改Tom类里面的study方法

public void study(){
        System.out.println("tom");
        iCourse.study();
    }

因为，课程和人也不应该死关联嘛！
类图

优点：减少类间的耦合性，提高代码的可维护性，降低修改程序所造成的风险

3.单一职责原则

概念：单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个导致类变更的原因。

解释
将类或者接口或者方法尽量划分到最小的部分，让它们各司其职，只拥有一项职责，减少耦合。

例子
假设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。如何解决这个问题呢？我们就要给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。

类单一职责

public class Course {

 public void study(String courseName)
 { 
 
 if("直播课".equals(courseName))
 { 
 System.out.println("不能快进"); 
 }
 
 else
 { 
 System.out.println("可以任意的来回播放"); 
 } 
 
 } 
}

从上面代码来看，Course 类承担了两种处理逻辑。假如，现在要对课程进行加密，那么直播课和录播课的加密逻辑都不一样，必须要修改代码。而修改代码逻辑势必会相互影响容易造成不可控的风险。 我们对职责进行分离解耦，来看代码，分别创建两个类 ReplayCourse 和 LiveCourse：

public class LiveCourse { 

public void study(String courseName)
{
System.out.println(courseName + "不能快进看"); 
} 

}

public class ReplayCourse { 

public void study(String courseName)
{ 
System.out.println("可以任意的来回播放"); 
} 

}

接口单一职责
业务继续发展，课程要做权限。没有付费的学员可以获取课程基本信息，已经付费的学员可以获得视频流，即学习权限。那么对于控制课程层面上至少有两个职责。我们可以把展示职责和管理职责分离开来，都实现同一个抽象依赖。设计一个顶层接口,创建 ICourse 接口：

public interface ICourse { 
//获得基本信息 
String getCourseName();
 //获得视频流 
 byte[] getCourseVideo(); 
 //学习课程 
 void studyCourse();
  //退款 
  void refundCourse(); 
}

我们可以把这个接口拆成两个接口，创建一个接口 ICourseInfo 和 ICourseManager：

public interface ICourseInfo { 
String getCourseName();
 byte[] getCourseVideo(); 
 }

public interface ICourseManager { 
void studyCourse(); 
void refundCourse(); 
}

方法单一职责
两种不符合的写法

private void modifyUserInfo(String userName,String address)
{ 
userName = "Tom";
 address = "Changsha"; 
 }

private void modifyUserInfo(String userName,String... fileds)
{ 
userName = "Tom"; 
// address = "Changsha"; 
}

private void modifyUserInfo(String userName,String address,boolean bool)
{ 
if(bool){
 }
 else{ 
 }
 userName = "Tom";
  address = "Changsha"; 
  }

显然，上面的 modifyUserInfo()方法中都承担了多个职责，既可以修改 userName,也可以修改 address，甚至更多，明显不符合单一职责。那么我们做如下修改，把这个方法拆成两个：

private void modifyUserName(String userName)
{ 
userName = "Tom";
}
private void modifyAddress(String address)
{ 
address = "Changsha";
 }

这修改之后，开发起来简单，维护起来也容易。

优点
降低类的复杂度
提高类的可读性
提高系统的可维护性
降低变更引起的风险

4.接口隔离原则

接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。

我们在设计接口时应当注意一下几点： 1、一个类对一类的依赖应该建立在最小的接口之上。 2、建立单一接口，不要建立庞大臃肿的接口。 3、尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。

接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性 和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更 的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。

例子
动物行为的抽象

接口

public interface IAnimal { 
void eat();
 void fly(); 
 void swim(); 
 }

实现类

public class Bird implements IAnimal
 { 
 @Override public void eat() {} 
 @Override public void fly() {}
  @Override public void swim() {} 
 }

实现类

public class Dog implements IAnimal {
 @Override public void eat() {}
  @Override public void fly() {} 
  @Override public void swim() {} 
  }

可以看出，Bird 的 swim()方法可能只能空着，但是空着，使用这种类的对象时发现还有这种方法，就会觉得很奇怪，Dog 的 fly()方法显然不可能的。这时候，我们针对 不同动物行为来设计不同的接口，分别设计 IEatAnimal，IFlyAnimal 和 ISwimAnimal 接口

public interface IEatAnimal { 
void eat();
 }

public interface IFlyAnimal { 
void fly(); 
}

public interface ISwimAnimal {
 void swim();
  }

Dog 只实现 IEatAnimal 和 ISwimAnimal 接口

public class Dog implements ISwimAnimal,IEatAnimal 
{ 
@Override public void eat() {}
 @Override public void swim() {} 
 }

类图对比

5.迪米特原则

概念：迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知 道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合。

解释
迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类， 而出现在方法体内部的类不属于朋友类。

例子
现在来设计一个权限系统，TeamLeader需要查看目前发布到线上的课程数量。这时候，TeamLeader 要找到员工 Employee 去进行统计，Employee 再把统计结果告诉 TeamLeader。

代码
课程类

public class Course { }

员工类

public class Employee{

 public void checkNumberOfCourses(List<Course> courseList)
 { 
 System.out.println("目前已发布的课程数量是：" + courseList.size()); 
 } 
 
 }

领导类

public class TeamLeader{ 

public void commandCheckNumber(Employee employee)
{ 
List<Course> courseList = new ArrayList<Course>(); 
for (int i= 0; i < 20 ;i ++)
{ 
courseList.add(new Course()); 
}
employee.checkNumberOfCourses(courseList); 
} 

}

测试类

public static void main(String[] args) { 
TeamLeader teamLeader = new TeamLeader();
 Employee employee = new Employee(); 
 teamLeader.commandCheckNumber(employee); 
 }

写到这里，其实功能已经都已经实现，代码看上去也没什么问题。根据迪米特原则，TeamLeader 只想要结果，不需要跟 Course 产生直接的交流。而 Employee 统计需要引用 Course 对象。TeamLeader 和 Course 并不是朋友，从下面的类图就可以看出来：

改造代码
员工类

public class Employee { 

public void checkNumberOfCourses(){ 
List<Course> courseList = new ArrayList<Course>(); 
for (int i= 0; i < 20 ;i ++)
{ 
courseList.add(new Course());
 }
 System.out.println("目前已发布的课程数量是："+courseList.size()); 
 } 
 
}

领导类

public class TeamLeader { 

public void commandCheckNumber(Employee employee)
{ 
employee.checkNumberOfCourses();
 } 
 
 }

再来看下面的类图，Course 和 TeamLeader 已经没有关联了。

6.里氏替换原则

概念：里氏替换原则（Liskov Substitution Principle,LSP）是指如果对每一个类型为 T1 的对象 o1,都有 类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没 有发生变化，那么类型 T2 是类型 T1 的子类型。

解释
可以理解为一个软件实体如果适用一个父类的话， 那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。

根据这个理解，我们总结一下： 引申含义：子类可以扩展父类的功能，但不能改变父类原有的功能。

1、子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2、子类中可以增加自己特有的方法。
3、当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入 参数更宽松。
4、当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输 出/返回值）要比父类更严格或相等。

在前面讲开闭原则的时候埋下了一个伏笔，我们记得在获取折后时重写覆盖了父类的 getPrice()方 法，增加了一个获取源码的方法 getOriginPrice()，显然就违背了里氏替换原则。我们修改一下代码， 不应该覆盖 getPrice()方法，增加 getDiscountPrice()方法：

public class JavaDiscountCourse extends JavaCourse 
{ 

public JavaDiscountCourse(Integer id, String name, Double price) 
{ 
super(id, name, price); 
}

public Double getDiscountPrice()
{ 
return super.getPrice() * 0.61; 
} 

}

优点
1、约束继承泛滥，开闭原则的一种体现。
2、加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低 需求变更时引入的风险。

例子
用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道 正方形是一个特殊的长方形，那么就可以创建一个长方形父类 Rectangle 类

public class Rectangle {
 private long height; 
 private long width; 
 
 public long getHeight() 
 { 
 return height; 
 }
 
 public void setHeight(long height) 
 { 
 this.height = height; 
 }

public long getWidth() 
{ 
return width; 
}

public void setWidth(long width) 
{ 
this.width = width; 
} 

}

创建正方形 Square 类继承长方形：

public class Square extends Rectangle { 

private long length; 

public long getLength() 
{ 
return length; 
}

public void setLength(long length) 
{ 
this.length = length; 
}

@Override 
public long getHeight() 
{ 
return getLength(); 
}

@Override
public void setHeight(long height) 
{ 
setLength(height); 
}

@Override 
public long getWidth() 
{ 
return getLength(); 
}

@Override 
public void setWidth(long width) 
{ 
setLength(width); 
} 

}

在测试类中创建 resize()方法，根据逻辑长方形的长应该大于等于宽，我们让高一直自增，知道高 等于宽变成正方形：

public static void resize(Rectangle rectangle){ 

while (rectangle.getWidth() >= rectangle.getHeight())
{ 
rectangle.setHeight(rectangle.getHeight() + 1); 
System.out.println("Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight()); 
}

System.out.println("Resize End,Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight()); 
}

测试代码

public static void main(String[] args) 
{ 
Rectangle rectangle = new Rectangle(); 
rectangle.setWidth(20); 
rectangle.setHeight(10); 
resize(rectangle); 
}

运行结果：

发现高比宽还大了，在长方形中是一种非常正常的情况。现在我们再来看下面的代码，把长方形 Rectangle 替换成它的子类正方形 Square，修改测试代码：

public static void main(String[] args) { 
Square square = new Square(); 
square.setLength(10); 
resize(square); 
}

这时候我们运行的时候就出现了死循环，违背了里氏替换原则，将父类替换为子类后，程序运行结 果没有达到预期。因此，我们的代码设计是存在一定风险的。里氏替换原则只存在父类与子类之间，约束继承泛滥。我们再来创建一个基于长方形与正方形共同的抽象四边形 Quadrangle 接口：

public interface QuadRangle { 
long getWidth(); 
long getHeight(); 
}

修改长方形 Rectangle 类

public class Rectangle implements QuadRangle { 

private long height; 
private long width; 

public long getHeight() 
{ 
return height; 
}

public void setHeight(long height) 
{ 
this.height = height; 
}

public long getWidth() 
{ 
return width;
}

public void setWidth(long width) 
{ 
this.width = width; 
} 

}

修改正方形类 Square 类

public class Square implements QuadRangle 
{ 

private long length; 

public long getLength() 
{
 return length; 
 }
 
 public void setLength(long length) 
 { 
 this.length = length; 
 }
 
 public long getWidth() 
 { 
 return length; 
 }
 
 public long getHeight() 
 { 
 return length; 
 } 
 
 }

此时，如果我们把 resize()方法的参数换成四边形 Quadrangle 类，方法内部就会报错。因为正方形 Square 已经没有了 setWidth()和 setHeight()方法了。因此，为了约束继承泛滥，resize()的方法参数只能用 Rectangle 长方形。

7.合成复用原则

合成复用原则（Composite/Aggregate Reuse Principle,CARP）是指尽量使用对象组合(has-a)/ 聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。

继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类 以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP 模型。

例子
以数据库操作为例

DBConnection 类

public class DBConnection { 

public String getConnection()
{ 
return "MySQL 数据库连接";
 } 
 
 }

ProductDao 类

public class ProductDao{ 
//这就体现了合成复用原则
private DBConnection dbConnection; 

public void setDbConnection(DBConnection dbConnection) 
{ 
this.dbConnection = dbConnection; 
}

public void addProduct()
{ 
String conn = dbConnection.getConnection(); 
System.out.println("使用"+conn+"增加产品"); 
} 

}

这就是一种非常典型的合成复用原则应用场景。但是，目前的设计来说，DBConnection 还不是一 种抽象，不便于系统扩展。目前的系统支持 MySQL 数据库连接，假设业务发生变化，数据库操作层要 支持 Oracle 数据库。当然，我们可以在 DBConnection 中增加对 Oracle 数据库支持的方法。但是违 背了开闭原则。其实，我们可以不必修改 Dao 的代码，将 DBConnection 修改为 abstract

public abstract class DBConnection { 

public abstract String getConnection(); 

}

public class MySQLConnection extends DBConnection 
{ 

@Override 
public String getConnection() 
{ 
return "MySQL 数据库连接"; 
} 

}

public class OracleConnection extends DBConnection 
{ 

@Override public String getConnection() 
{ 
return "Oracle 数据库连接"; 
} 

}

具体选择交给应用层，来看一下类图