02. 原件设计七大原则

时间 2021-02-27

标签前端 java mysql sql 数据库编程设计模式架构 oracle 框架栏目 Java 繁體版

原文原文链接

课程目标前端

一、经过对节课内容的学习，了解设计原则的重要性。java

二、掌握七大设计原则的具体内容。mysql

内容定位sql

学习设计原则，学习设计模式的基础。在实际开发过程当中，并非必定要求全部代码都遵循设计原则，咱们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助咱们设计出更加优雅的代码结构。数据库

1、开闭原则

1. 定义

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

2. 优势

一、开闭原则，是面向对象设计中最基础的设计原则。它指导咱们如何创建稳定灵活的系统，例如：咱们版本更新，我尽量不修改源代码，可是能够增长新功能设计模式

二、所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。能够提升软件系统的可复用性及可维护性架构

三、实现开闭原则的核心思想就是面向抽象编程oracle

3. 代码展现

首先建立一个课程接口框架

//课程接口
public interface ICourse {
    Integer getId();
    String getName();
    Double getPrice();
}

整个课程生态有 Java 架构、大数据、人工智能、前端、软件测试等，咱们来建立 Java架构课程

//Java架构课程
public class JavaCourse implements ICourse{
    private Integer id;
    private String name;
    private Double price;
    public Integer getId() {
        return this.id;
    }
    public String getName() {
        return this.name;
    }
    public Double getPrice() {
        return this.price;
    }
    public JavaCourse(Integer id, String name, Double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }
}

//测试
public static void main(String[] args) {
    ICourse iCourse = new JavaDisCountCourse(1, "Java架构", 11800D);
    System.out.println("课程ID：" + iCourse.getId() +
                       "\n课程标题：《" + iCourse.getName() + "》" +
                       "\n课程售价：" + iCourse.getPrice());
}

一、如今咱们要给 Java 架构课程作活动，价格优惠。若是修改 JavaCourse 中的 getPrice() 方法，则会存在必定的风险，可能影响其余地方的调用结果。

二、咱们如何在不修改原有代码前提早下，实现价格优惠这个功能呢？如今，咱们再写一个处理优惠逻辑的类 JavaDiscountCourse （思考一下为何要叫JavaDiscountCourse，而不叫 DiscountCourse）

//处理优惠逻辑类
public class JavaDisCountCourse extends JavaCourse{
    public JavaDisCountCourse(Integer id, String name, Double price) {
        super(id, name, price);
    }
    //原价拿不到
    /*@Override
    public Double getPrice() {
        return super.getPrice() * 0.6;
    }*/
    public Double getDisCountPrice(){
        return super.getPrice() * 0.6;
    }
}

//测试
public static void main(String[] args) {
    ICourse iCourse = new JavaDisCountCourse(1, "Java架构", 11800D);
    JavaDisCountCourse course = (JavaDisCountCourse) iCourse;
    System.out.println("课程ID：" + course.getId() +
                       "\n课程标题：《" + course.getName() + "》" +
                       "\n课程原价：" + course.getPrice() +
                       "\n课程售价：" + course.getDisCountPrice());
}

类图展现：

2、依赖倒置原则

1. 定义

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

2. 优势

一、抽象不该该依赖细节，细节应该依赖抽象

二、针对接口编程，不要针对实现编程

三、能够减小类与类之间的耦合性，提升系统的稳定性，提升代码的可读性和可维护性，并可以下降修改程序所形成的风险

3. 代码展现

首先建立一个类 Tom

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

调用一下

public static void main(String[] args) {
    //应用层为高层
    Tom tom = new Tom();
    tom.studyJavaCourse();
    tom.studyPythonCourse();
    tom.studyAICourse();
}

Tom 热爱学习，目前正在学习 Java 课程和 Python 课程。你们都知道，学习也是会上瘾的。随着学习兴趣的暴涨，如今 Tom 还想学习 AI 人工智能的课程。这个时候，业务扩展，咱们的代码要从底层到高层（调用层）一次修改代码。在 Tom 类中增长 studyAICourse() 的方法，在高层也要追加调用。如此一来，系统发布之后，其实是很是不稳定的，在修改代码的同时也会带来意想不到的风险

来咱们优化代码，建立一个课程的抽象ICourse 接口：

public interface ICourse {
    void study();
}

而后写 JavaCourse 类

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

再实现 PythonCourse 类

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

修改 Tom 类

public class Tom {
    public void  study(ICourse iCourse){
        iCourse.study();
    }
}

来调一下

public static void main(String[] args) {
    //应用层为高层
    Tom tom = new Tom();
    //注入的方式实现依赖倒置
    tom.study(new JavaCourse());
    tom.study(new PythonCourse());
}

咱们这时候再看来代码，Tom 的兴趣不管怎么暴涨，对于新的课程，我只须要新建一个类，经过传参的方式告诉Tom，而不须要修改底层代码。实际上这是一种你们很是熟悉的方式，叫依赖注入。

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

//构造器注入
public class Tom {
    private ICourse iCourse;
    public Tom(ICourse iCourse) {
        this.iCourse = iCourse;
    }
    public void study(){
        iCourse.study();
    }
}
//调用
public static void main(String[] args) {
    Tom tom = new Tom(new JavaCourse());
    tom.study();
}

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

//set注入
public class Tom {
    private ICourse iCourse;

    public void setiCourse(ICourse iCourse) {
        this.iCourse = iCourse;
    }
    public void study(){
        iCourse.study();
    }
}
//调用
public static void main(String[] args) {
    Tom tom = new Tom();
    tom.setiCourse(new JavaCourse());
    tom.study();
}

类图展现：

3、单一职责原则

1. 定义

单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个致使类变动的缘由

一个类，接口，方法只负责一项职责

2. 优势

一、下降类的复杂度

二、下降变动引发的风险

三、提升类的可读性

四、提升系统的可维护性

3. 代码展现

咱们的课程有直播课和录播课。直播课不能快进和快退，录播能够能够任意的反复观看，功能职责不同。

仍是先建立一个Course 类：

public class Course {
    public void study(String courseName){
        if("直播课".equals(courseName)){
            System.out.println("不能快进");
        }else{
            System.out.println("任意播放");
        }
    }
}
//代码调用
public static void main(String[] args) {
    Course course = new Course();
    course.study("直播课");
    course.study("录播课");
}

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

//直播
public class LiveCourse {
    public void study(String courseName){
        System.out.println("不能快进");
    }
}
//录播
public class ReplayCourse {
    public void study(String courseName){
        System.out.println("任意播放");
    }
}
//调用代码
public static void main(String[] args) {
    LiveCourse liveCourse = new LiveCourse();
    liveCourse.study("直播课");
    ReplayCourse replayCourse = new ReplayCourse();
    replayCourse.study("录播课");
}

业务继续发展，课程要作权限。没有付费的学员能够获取课程基本信息，已经付费的学员能够得到视频流，即学习权限。那么对于控制课程层面上至少有两个职责。咱们能够把展现职责和管理职责分离开来，都实现同一个抽象依赖。

设计一个顶层接口,建立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();
}

来看下类图：

下面咱们来看一下方法层面的单一职责设计。有时候，咱们为了偷懒，一般会把一个方法写成下面这样

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

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

private void modifyUserName(String userName){
}
private void modifyAddress(String address){
}

这修改以后，开发起来简单，维护起来也容易。可是，咱们在实际开发中会项目依赖，组合，聚合这些关系，还有还有项目的规模，周期，技术人员的水平，对进度的把控，不少类都不符合单一职责。可是，咱们在编写代码的过程，尽量地让接口和方法保持单一职责，对咱们项目后期的维护是有很大帮助的

4、接口隔离原则

1. 定义

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

2. 注意

一、一个类对一类的依赖应该创建在最小的接口之上。
二、创建单一接口，不要创建庞大臃肿的接口。
三、尽可能细化接口，接口中的方法尽可能少（不是越少越好，必定要适度）

3. 优势

符合咱们常说的高内聚低耦合的设计思想，从而使得类具备很好的可读性、可扩展性和可维护性

4. 代码展现

//接口
public interface IAnimal {
    void eat();
    void fly();
    void swim();
}
//鸟
public class Bird implements IAnimal{
    public void eat() {
    }
    public void fly() {
    }
    public void swim() {
    }
}
//狗
public class Dog implements IAnimal{
    public void eat() {
    }
    public void fly() {
    }
    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();
}
//鸟
public class Bird implements IEatAnimal,IFlyAnimal{
    public void eat() {
    }
    public void fly() {
    }
}
//狗
public class Dog implements IEatAnimal,ISwimAnimal{
    public void eat() {
    }
    public void swim() {
    }
}

来看下两种类图对比，仍是很是清晰明了的

5、迪米特法则

1. 定义

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

2. 优势

一、下降类之间的耦合

二、迪米特原则主要强调只和朋友交流，不和陌生人说话

三、出如今成员变量、方法的输入、输出参数中的类均可以称之为成员朋友类，而出如今方法体内部的类不属于朋友类。

代码展现

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

//课程
public class Course {
}
//员工
public class Employee {
    public void checkNumberOfCourse(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.checkNumberOfCourse(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、里氏替换原则

1. 定义

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

定义看上去仍是比较抽象，咱们从新理解一下，能够理解为一个软件实体若是适用一个父类的话，那必定是适用于其子类，全部引用父类的地方必须能透明地使用其子类的对象，子类对象可以替换父类对象，而程序逻辑不变

引伸含义：子类能够扩展父类的功能，但不能改变父类原有的功能。

一、子类能够实现父类的抽象方法，但不能覆盖父类的非抽象方法。

二、子类中能够增长本身特有的方法。

三、当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。

四、当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类更严格或相等。

在前面讲开闭原则的时候埋下了一个伏笔，咱们记得在获取折后时重写覆盖了父类的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;
    }
}

2. 优势

一、约束继承泛滥，开闭原则的一种体现
二、增强程序的健壮性，同时变动时也能够作到很是好的兼容性，提升程序的维护性、扩展性。下降需求变动时引入的风险。

3. 代码展现

如今来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，咱们都知道正方形是一个特殊的长方形

//长方形
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;
    }
}
//正方形继承长方形
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);
}
/*
结果
width:20,height11
width:20,height12
width:20,height13
width:20,height14
width:20,height15
width:20,height16
width:20,height17
width:20,height18
width:20,height19
width:20,height20
width:20,height21
*/

发现高比宽还大了，在长方形中是一种很是正常的状况。如今咱们再来看下面的代码，把长方形 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();
}
//修改长方形
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;
	}
}
//修改正方形
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、合成复用原则

1. 定义

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

继承咱们叫作白箱复用，至关于把全部的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类之外的对象是没法获取到实现细节的。要根据具体的业务场景来作代码设计，其实也都须要遵循 OOP 模型

2. 优势

可使系统更加灵活，下降类与类之间的耦合，一个类的变化对其它类的影响相对较小

3. 代码展现

//以数据库操做为例，先来建立DBConnection 类
public class DBConnection {
    public String getConnection(){
         return "MySQL 数据库链接";
    }
}
//Dao类
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();
}
//mysql
public class MySQLConnection extends DBConnection {
    @Override
    public String getConnection() {
    	return "MySQL 数据库链接";
    }
}
//oracle
public class OracleConnection extends DBConnection {
    @Override
    public String getConnection() {
    	return "Oracle 数据库链接";
    }
}

设计原则总结

学习设计原则，学习设计模式的基础。在实际开发过程当中，并非必定要求全部代码都遵循设计原则，咱们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助咱们设计出更加优雅的代码结构。