死磕设计模式-为什么要从设计模式开始

死磕设计模式-为什么要从设计模式开始

设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

Open-Closed Principle开闭原则

	开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，

开闭原则定义

开闭原则的定义: 一个软件实体,如类、模块和函数应该对扩展开放,对修改关闭.即一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化.
软件实体包括一下部分
	1、项目或软件产品中按照一定的逻辑规则划分的模块
	2、抽象和类
	3、方法
注意: 开闭原则对扩展开放,对修改关闭,并不意味着不做任何修改,底层模块的变更,必然要有高层模块进行耦合,否则就是一个孤立无意义的代码片段

案例代码实战

IShop 定义了3个属性 名称、价格、数量

/**
 * 商品接口类
 */
public interface  IShop {
    /**
     * 商品名称
     */
    public String getName();
    /**
     * 商品价格
     */
    public double getPrice();

    /**
     * 商品数量
     */
    public int getNumber();
}

RioShop 实现类

package com.sundablog.ocp.service.impl;

import com.sundablog.ocp.service.IShop;

public class RioShop implements IShop {

    /**
     * 商品名称
     */
    private String name;
    /**
     * 商品的价格
     */
    private double price;
    /**
     * 商品的数量
     */
    private int number;

    /**
     * 通过构造函数传递商品数据
     * @param name 商品名称
     * @param price 商品价格
     * @param number 商品数量
     */
    public RioShop(String name,double price,int number){
        this.name = name;
        this.price = price;
        this.number = number;
    }


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

    @Override
    public double getPrice() {
        return this.price;
    }

    @Override
    public int getNumber() {
        return this.number;
    }
}

store 商店是负责卖出商品的

package com.sundablog.ocp;

import com.sundablog.ocp.service.IShop;
import com.sundablog.ocp.service.impl.RioShop;

import java.util.ArrayList;
import java.util.List;

/**
 * 商店类
 */
public class store {

    private final static List<IShop> shopList = new ArrayList<IShop>();
    //static静态模块初始化数据， 实际项目中一般是由持久层完成
    static {
        shopList.add(new RioShop("苹果鸡尾酒", 13.5, 500));
        shopList.add(new RioShop("葡萄鸡尾酒", 13.5, 200));
        shopList.add(new RioShop("红酒鸡尾酒", 13.5, 100));
        shopList.add(new RioShop("哈密瓜鸡尾酒", 13.5, 300));
    }
    //模拟商店卖出商品
    public static void main(String[] args) {
        for (IShop iShop : shopList) {
            System.out.println("商品名称" + iShop.getName());
            System.out.println("商品数量"+iShop.getNumber());
            System.out.println("商品价格"+iShop.getPrice());
        }

    }

}

现在RIO 这款商品不好买 商店要打0.9折 我们在写一个打折的逻辑处理类 RioDiscountShop 是打折处理类

package com.sundablog.ocp.service.impl;

public class RioDiscountShop extends RioShop {
    /**
     * 通过构造函数传递商品数据
     *
     * @param name   商品名称
     * @param price  商品价格
     * @param number 商品数量
     */
    public RioDiscountShop(String name, double price, int number) {
        super(name, price, number);
    }

    /**
     * 不打折前价格
     * @return
     */
    public double getOriginPrice(){
        return super.getPrice();
    }

    @Override
    public double getPrice(){
        return super.getPrice() * 0.9;
    }
}

//模拟商店卖出商品
    public static void main(String[] args) {
        RioDiscountShop rioDiscountShop = new RioDiscountShop("苹果鸡尾酒",13.5,500);
        System.out.println("原来的价格:"+rioDiscountShop.getOriginPrice()+"打折后的价格:"+rioDiscountShop.getPrice());

    }

Dependence Inversion Principle依赖倒置原则

依赖倒置原则定义

依赖倒置原则（Dependence Inversion Principle,DIP）是指设计代码结构时，高层模块不应该依
赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖抽象。通过依赖倒置，可以
减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并能够降低修改程序所
造成的风险

案例代码实战

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 热爱学习，目前正在学习 Java 课程和 Python 课程。大家都知道，学习也是会上瘾的。随着学习兴趣的暴涨，现在 Tom 还想学习 AI 人工智能的课程。这个时候，业务扩展，我们的代码要从底层到高层（调用层）一次修改代码。在 Tom 类中增加 studyAICourse()的方法，在高层也要追加调用。如此一来，系统发布以后，实际上是非常不稳定的，在修改代码的同时也会带来意想不到的风险。接下来我们优化代码，创建一个课程的抽象 ICourse 接口：

public interface ICourse {
	void study();
}

然后写 JavaCourse 类：

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

再实现 PythonCourse 类：

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，而不需要修改底层代码。实际上这是一种大家非常熟悉的方式，叫依赖注入。注入的方式还有构造器方式和 setter 方式。我们来看构造器注入方式：

public class Tom {
    private ICourse course;
    public Tom(ICourse course){
    	this.course = course;
    }
    public void study(){
    	course.study();
    }
}

看调用代码：

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

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

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

看调用代码：

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

Simple Responsibility Principle单一职责原则

单一职责原则定义

单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个导致类变更的原因。假设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。如何解决这个问题呢？我们就要给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可 读 性 ， 提 高 系 统 的 可 维 护 性 ， 降 低 变 更 引 起 的 风 险 。 总 体 来 说 就 是 一个Class/Interface/Method 只负责一项职责。

案例代码实战

Course 类：

public class Course {
    public void study(String courseName){
    if("直播课".equals(courseName)){
    	System.out.println(courseName + "不能快进");
    }else{
    	System.out.println(courseName + "可以反复回看");
    }
}

看代码调用：

public static void main(String[] args) {
    Course course = new Course();
    course.study("直播课");
    course.study("录播课");
}

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

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

ReplayCourse 类：

public class ReplayCourse {
    public void study(String courseName){
        System.out.println(courseName + "可以反复回");
    }
}

调用代码：

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：ICourseInfo 接口：

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

ICourseManager 接口：

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";
}

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

Interface Segregation Principle接口隔离原则

接口隔离原则定义

接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使
用单一的总接口，客户端不应该依赖它不需要的接口。这个原则指导我们在设计接口时
应当注意一下几点：
1、一个类对一类的依赖应该建立在最小的接口之上。
2、建立单一接口，不要建立庞大臃肿的接口。
3、尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。

案例代码实战

IAnimal 接口

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

Bird 类实现

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

Dog 类实现：

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

可以看出，Bird 的 swim()方法可能只能空着，Dog 的 fly()方法显然不可能的。这时候，我们针对不同动物行为来设计不同的接口，分别设计 IEatAnimal，IFlyAnimal 和 ISwimAnimal 接口，来看代码：

IEatAnimal 接口

public interface IEatAnimal {
	void eat();
}

IFlyAnimal 接口：

public interface IFlyAnimal {
	void fly();
}

ISwimAnimal 接口：

public interface ISwimAnimal {
	void swim();
}

Dog 只实现 IEatAnimal 和 ISwimAnimal 接口：

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

Law of Demeter 迪米特法则

迪米特法则原则定义

迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合。迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类，而出现在方法体内部的类不属于朋友类。
现在来设计一个权限系统，TeamLeader需要查看目前发布到线上的课程数量。这时候，TeamLeader要找到员工 Employee 去进行统计，Employee 再把统计结果告诉 TeamLeader。接下来我们还是来看

案例代码实战

Course 类

public class Course {
}

Employee 类：

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

TeamLeader 类：

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 class LodTest {

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

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

下面来对代码进行改造：

Employee 类：

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());
    }
}

TeamLeader 类：

public class TeamLeader {

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

学习软件设计原则，千万不能形成强迫症。碰到业务复杂的场景，我们需要随机应变。

Liskov Substitution Principle里氏替换原则

里氏替换原则定义

​ 里氏替换原则（Liskov Substitution Principle,LSP）是指如果对每一个类型为 T1 的对象 o1,都有类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
​ 定义看上去还是比较抽象，我们重新理解一下，可以理解为一个软件实体如果适用一个父类的话，那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。根据这个理解，我们总结一下：
​ 引申含义：子类可以扩展父类的功能，但不能改变父类原有的功能。
​ 1、子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
​ 2、子类中可以增加自己特有的方法。
​ 3、当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。
​ 4、当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类更严格或相等。

里氏替换原则优点

​ 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);
    }

测试结果

Width:20,Height:11
Width:20,Height:12
Width:20,Height:13
Width:20,Height:14
Width:20,Height:15
Width:20,Height:16
Width:20,Height:17
Width:20,Height:18
Width:20,Height:19
Width:20,Height:20
Width:20,Height:21
Resize End,Width:20,Height:21

发现高比宽还大了，在长方形中是一种非常正常的情况。现在我们再来看下面的代码，把长方形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 长方形。

Composite&Aggregate Reuse Principle合成复用原则

合成复用原则定义

合成复用原则（Composite/Aggregate Reuse Principle,CARP）是指尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP
模型

案例代码实战

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();
}

然后，将 MySQL 的逻辑抽离：

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

再创建 Oracle 支持的逻辑：

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

设计原则总结

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