三、设计模式的七大原则

3.1 单一职责原则

3.1.1 介绍

单一职责原则（Single Responsibility Principle，SRP）一个对象应该只包含单一的职责。并将该职责完整的封装到一个类中。即一个类应该只负责一项职责，来达到程序的高内聚、低耦合

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

• 1）一个职责的变化可能会影响这个类实现其他职责的能力；

• 2）当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2；

3.1.2 应用示例

• 案例：

package com.dfbz.demo01_单一职责原则;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Employee {

    public void coding() {
        System.out.println("程序员敲代码");
    }

    public void sortingData() {
        System.out.println("行政人员整理资料");
    }

}

在上述程序中，违反了单一职责原则，一个类中应该只负责一个事情，多件事情应该交给多个类来完成；优化如下：

• 程序员类：

package com.dfbz.demo01_单一职责原则;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Programmer {
    public void coding() {
        System.out.println("程序员敲代码");
    }
}

• 行政人员类：

package com.dfbz.demo01_单一职责原则;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Administrative {
    void sortingData() {
        System.out.println("行政人员整理资料");
    }
}

Tips：单一职责对扩展开放，对修改关闭，降低维护带来的新风险

3.2 接口隔离原则

3.2.1 介绍

接口隔离原则（Interface Segregation Principle，ISP）：将大的接口分成多个小的独立接口，在Java中支持接口的多实现，可以很容易的让类具有多种接口的特征，同时每个类可以选择性地只实现目标接口。客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

3.2.2 应用示例：

• 场景：

  • 1）定义一个电子设备接口，具备拍照、听音乐、语音等功能；

  • 2）定义相机类（能拍照），实现电子设备接口

  • 3）定义MP3类（能拍照、听音乐），实现电子设备接口

  • 4）定义手机类（能拍照、听音乐、语音），实现电子设备接口

• 电子设备接口：

package com.dfbz.demo02_接口隔离原则.测试;

//  电子设备接口
public interface DianZiSheBei {

    // 拍照
    void takePhoto();
    
    // 听音乐
    void music();

    // 语音
    void voice();
}

• 相机类：

package com.dfbz.demo02_接口隔离原则.测试;

/**
 * @author lscl
 * @version 1.0
 * @intro: 相机类
 */
public class Camera implements DianZiSheBei {
    
    @Override
    public void takePhoto() {
        System.out.println("拍照~");
    }
    
    @Override
    public void music() {

    }

    @Override
    public void voice() {

    }

}

• MP3：

package com.dfbz.demo02_接口隔离原则.测试;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class MP3 implements DianZiSheBei {
    @Override
    public void music() {
        System.out.println("听音乐~");
    }

    @Override
    public void takePhoto() {
        System.out.println("拍照~");
    }

    @Override
    public void voice() {

    }
}

• 手机：

package com.dfbz.demo02_接口隔离原则.测试;

/**
 * @author lscl
 * @version 1.0
 * @intro: 对讲机类
 */
public class Phone implements DianZiSheBei {
    @Override
    public void music() {
        System.out.println("听音乐~");
    }

    @Override
    public void voice() {
        System.out.println("语音~");
    }

    @Override
    public void takePhoto() {
        System.out.println("拍照~");
    }
}

我们不难发现，当相机、MP3、对讲机等需要具备某项功能时不得不重写不必要的方法，即电子设备接口不是最小接口；

3.2.3 案例优化：

• 优化：

  • 1）定义拍照、听音乐、语音三个接口；
  • 2）相机、MP3、手机等电子设备按需实现对应接口；

• 听音乐接口：

package com.dfbz.demo02_接口隔离原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro: 听音乐接口
 */
public interface Music {
    void music();
}

• 拍照接口：

package com.dfbz.demo02_接口隔离原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro: 拍照接口
 */
public interface TakePhoto {
    void takePhoto();
}

• 语音接口：

package com.dfbz.demo02_接口隔离原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro: 语音接口
 */
public interface Voice {
    void voice();
}

• 相机类：

package com.dfbz.demo02_接口隔离原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro: 相机类
 */
public class Camera implements TakePhoto {
    @Override
    public void takePhoto() {
        System.out.println("拍照~");
    }
}

• MP3类：

package com.dfbz.demo02_接口隔离原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class MP3 implements TakePhoto,Music {
    @Override
    public void music() {
        System.out.println("听音乐~");
    }

    @Override
    public void takePhoto() {
        System.out.println("拍照~");
    }
}

• 手机类：

package com.dfbz.demo02_接口隔离原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro: 对讲机类
 */
public class Phone implements TakePhoto,Music,Voice {
    @Override
    public void music() {
        System.out.println("听音乐~");
    }

    @Override
    public void voice() {
        System.out.println("语音~");
    }

    @Override
    public void takePhoto() {
        System.out.println("拍照~");
    }
}

3.3 开闭原则

3.3.1 介绍

开闭原则（Open Closed Principle，OCP）是编程中最基础、最重要的设计原则，开闭原则的中心思想是：一个软件实体应当具备“对扩展开放，对修改关闭”的原则

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

3.3.2 应用示例

package com.dfbz.demo03_开闭原则.测试;

import org.junit.Test;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {

    @Test
    public void test1() {

        JDBC jdbc=new JDBC();
        jdbc.connectMySQL(new MySQLDriver());
        jdbc.connectOracle(new OracleDriver());
    }
}

class JDBC{
    public void connectMySQL(MySQLDriver mySQLDriver){
        mySQLDriver.getConnection();
    }
    public void connectOracle(OracleDriver oracleDriver){
        oracleDriver.getConnection();
    }
}

class MySQLDriver{
    public void getConnection() {
        System.out.println("连接MySQL");
    }
}

class OracleDriver{
    public void getConnection() {
        System.out.println("连接Oracle");
    }
}

上述代码中违反了开闭原则，不难想象，如果我们还想要连接SQL Server数据库，必须修改JDBC类的代码，增加一个connectSqlServer方法，然后再提供一个SqlServerDriver类

3.3.3 案例优化

package com.dfbz.demo03_开闭原则.优化;

import org.junit.Test;

public class Demo01 {
    @Test
    public void test() {
        JDBC jdbc=new JDBC();
        jdbc.connectDB(new MySQLDriver());
        jdbc.connectDB(new OracleDriver());
        jdbc.connectDB(new SqlServerDriver());
    }

}

class JDBC{
    void connectDB(Driver driver){
        driver.getConnection();
    }
}

interface class Driver {
    // 定义抽象连接方法
    public abstract void getConnection();
}

class MySQLDriver implements Driver{

    @Override
    public void getConnection() {
        System.out.println("连接MySQL");
    }
}

class OracleDriver implements Driver{

    @Override
    public void getConnection() {
        System.out.println("连接Oracle");
    }
}
class SqlServerDriver implements Driver{

    @Override
    public void getConnection() {
        System.out.println("连接SqlServer");
    }
}

3.3 里氏替换原则

3.3.1 介绍

里氏替换原则（Liskov Substitution Principle，LSP）：该原则主要阐述了有关继承的一些原则；

里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

Tips：里氏替换原则是实现开闭原则的重要方式之一。

3.3.2 应用示例

企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能

分析：鸟一般都会飞行，如燕子的飞行速度大概是每小时 120 千米。企鹅虽然属于鸟类，但并不会飞。假如要设计一个实例，计算这两种鸟飞行 240 千米要花费的时间。显然，拿燕子来测试这段代码，结果正确，能计算出所需要的时间；但拿企鹅来测试，结果则会出现异常：

package com.dfbz.demo04_里氏替换原则.测试;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
    public static void main(String[] args) {
        // 燕子类
        Bird swallow = new Swallow();
        // 燕子的飞行速度为120km/h
        swallow.setFlySpeed(120);
        double swallowFlyTime = swallow.getFlyTime(240);
        System.out.println("燕子飞行120km需要:" + swallowFlyTime + "小时");

        // 企鹅类
        Bird penguin = new Penguin();
        // 企鹅不会飞
        penguin.setFlySpeed(0);

        double penguinFlyTime = penguin.getFlyTime(240);			// 出现异常
        System.out.println("企鹅飞行120km需要:" + penguinFlyTime + "小时");		

    }
}

// 鸟类
class Bird {
    // 飞行速度
    private Integer flySpeed;

    public Integer getFlySpeed() {
        return flySpeed;
    }

    public void setFlySpeed(Integer flySpeed) {
        this.flySpeed = flySpeed;
    }

    // 根据飞行举例计算飞行时间
    public Integer getFlyTime(Integer distance) {
        return (distance / flySpeed);
    }
}

// 燕子类
class Swallow extends Bird {

}

// 企鹅类
class Penguin extends Bird {

}

3.3.3 案例优化

上诉代码中违反了里氏替换原则，即子类可以扩展父类的功能，但不能改变父类原有功能；我们需要重新设计继承体系：

• 1）设计顶层父类：鸟类
• 2）将鸟类划分为会飞的鸟类和不会飞的鸟类

package com.dfbz.demo04_里氏替换原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
}

// 鸟类
class Bird {

}

// 飞行类的鸟
class FlyBird extends Bird{
    // 飞行速度
    private Integer flySpeed;

    public Integer getFlySpeed() {
        return flySpeed;
    }

    public void setFlySpeed(Integer flySpeed) {
        this.flySpeed = flySpeed;
    }

    // 根据飞行举例计算飞行时间
    public Integer getFlyTime(Integer distance) {
        return (distance / flySpeed);
    }
}

// 陆地类的鸟
class LandBird extends Bird{

}

// 燕子类(飞行类)
class Swallow extends FlyBird {

}

// 企鹅类(陆地类)
class Penguin extends LandBird {

}

3.4 依赖倒转原则

3.4.1 介绍

依赖倒转原则（Dependence Inversion Principle，DIP）：依赖倒转的中心思想就是面向接口编程

依赖倒转原则的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类

使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

3.4.2 应用示例

• 场景：
  • 1）定义一个榨汁机类，可以榨汁苹果，获取苹果的营养价值；

package com.dfbz.demo05_依赖倒转原则.测试;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
    public static void main(String[] args) {
        Juicer juicer = new Juicer();

        // 榨了一杯苹果汁~ 生津止渴、健脾养心、补血安神
        juicer.juicing(new Apple());
    }
}


class Apple {
    public String getNutrition() {
        return "生津止渴、健脾养心、补血安神";
    }
}

// 榨汁机
class Juicer {

    public void juicing(Apple apple) {
        apple.getNutrition();
    }
}

3.4.3 案例优化

上述代码违反了依赖倒转原则，如果需要榨梨子汁、西瓜汁就必须修改源代码，在榨汁机类中扩展多个榨汁方法；我们抽取顶层接口，将功能抽象，留给子类实现；

package com.dfbz.demo05_依赖倒转原则.优化;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
    public static void main(String[] args) {
        Juicer juicer = new Juicer();

        // 榨了一杯苹果汁~ 生津止渴、健脾养心、补血安神
        juicer.juicing(new Apple());

        // 榨了一杯梨子汁~ 生津润燥，清热化痰，解酒
        juicer.juicing(new Pear());
    }
}
// 将水果模块抽象为一个接口：可以是苹果、梨子、香蕉等
interface IFruit{
    // 获取该水果的营养
    String getNutrition();
}


class Apple implements IFruit {
    public String getNutrition() {
        return "生津止渴、健脾养心、补血安神";
    }
}
class Pear implements IFruit {
    public String getNutrition() {
        return "生津润燥，清热化痰，解酒";
    }
}

// 榨汁机
class Juicer {

    public void juicing(IFruit fruit) {
        fruit.getNutrition();
    }
}

3.6 迪米特法则

3.6.1 介绍

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP）：即一个类对自己依赖的类知道的越少越好，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息；

迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。

其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

Tips：过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

迪米特法则强调了下面两点：

• 1）从被依赖者的角度：只暴露应该暴露的方法或属性，即编写相关的类时确定方法和属性的权限
• 2）从依赖者的角度来看，只依赖应该依赖的对象

3.6.2 应用示例

1）案例1

从被依赖者的角度：只暴露应该暴露的方法或属性，即编写相关的类时确定方法和属性的权限

• 在驾照科三时，规则是上车准备、调整座位、系安全带、踩离合、挂挡，期间操作顺序不能乱；

package com.dfbz.demo06_迪米特法则.测试1;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
    public static void main(String[] args) {
        Car car=new Car();

        /*
            正常情况下我们直接调用start方法即可,
            但是现在发现Car所有的方法都是公开的,于是你就写了以下的流程
         */
        car.clutch();
        car.seat();
        car.putIntoGear();

        // 或者是这样的操作
        car.safetyBelt();
        car.seat();
        car.putIntoGear();
        
        // 还可能是这样的操作
        car.start();
        car.clutch();
    }
}

class Car {
    // 上车准备
    public void getOnPrepare(){}

    // 调整座位
    public void seat(){}

    // 系安全带
    public void safetyBelt(){}

    // 踩离合
    public void clutch(){}

    // 挂挡
    public void putIntoGear(){}

	// 合格步骤
    public void start(){
        getOnPrepare();
        seat();
        safetyBelt();
        clutch();
    }
}

根据迪米特法则，只暴露应该暴露的方法或属性

• 优化：

package com.dfbz.demo06_迪米特法则.优化1;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
    public static void main(String[] args) {

    }
}
class Person{
    private Car car;

    public Car getCar() {
        return car;
    }

    public void setCar(Car car) {
        this.car = car;
    }

    // 开车
    public void driverCar(){
        car.start();
    }
}
class Car {
    // 上车准备
    private void getOnPrepare(){}

    // 调整座位
    private void seat(){}

    // 系安全带
    private void safetyBelt(){}

    // 踩离合
    private void clutch(){}

    // 挂挡
    private void putIntoGear(){}

    // 起步
    public void start(){
        getOnPrepare();
        seat();
        safetyBelt();
        clutch();
    }
}

2）案例2

• 案例：张三叫李四办件事，李四办不了，叫王五办；

package com.dfbz.demo06_迪米特法则.测试2;

import java.util.List;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
}
class Zhangsan{
    public Lisi getLisi(){
        return new Lisi();
    }
    public void work(){
        
        // 叫李四做
        Lisi lisi=new Lisi();
        
        // 李四叫王五做
        Wangwu wangwu = lisi.getWangwu();
        
        // 王五把事情做好了
        wangwu.work();
    }
}

class Lisi{
    public Wangwu getWangwu(){
        return new Wangwu();
    }
}

class Wangwu{
    public void work(){
        System.out.println("so easy~");
    }
}

• 优化：

package com.dfbz.demo06_迪米特法则.优化2;

import java.util.List;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
}
class Zhangsan{
    public Lisi getLisi(){
        return new Lisi();
    }
    public void work(){

        // 叫李四做
        Lisi lisi=new Lisi();

        // 不管用什么办法,让李四搞定
        lisi.work();
    }
}

class Lisi{
    
    public void work(){
        
        // 李四叫王五搞定
        Wangwu wangwu = getWangwu();
        wangwu.work();
    }
    public Wangwu getWangwu(){
        return new Wangwu();
    }
}

class Wangwu{
    public void work(){
        System.out.println("so easy~");
    }
}

3.7 合成复用原则

3.7.1 介绍

合成复用原则（Composite Reuse Principle，CRP）：它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

Tips：如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。

1. 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为**“白箱”复用**。
2. 子类与父类的耦合度高。父类功能的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
3. 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。

1. 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为黑箱复用。
2. 新旧类之间的耦合度低。这种复用所需的依赖较少，这种复用可以在运行时动态进行，可以根据程序的需要传递（多态，可以传递不同的子类）。

• 白箱复用：

class A{
    public void method(){}
}
class B extends A{}

• 黑箱复用：

class A{
    public void method(){}
}
class SubA extends A{
    
}
class B{
    private A a;
    public B(A a){}			// 可以传递SubA对象进来
}

3.7.2 应用示例

分析：汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。

代码示例：

package com.dfbz.demo07_合成复用原则.测试;

/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
    public static void main(String[] args) {
        
        // 黑色电动车
        Car car=new RedElectricCar();
    }
}

class Car{}

// 汽油车
class GasolineCar extends Car{}

// 电动车
class ElectricCar extends Car{}

// 红色汽油车
class RedGasolineCar extends GasolineCar{}

// 黑色汽油车
class BlackGasolineCar extends GasolineCar{}

// 红色电动车
class RedElectricCar extends ElectricCar{}

// 黑色汽油车
class BlackElectricCar extends ElectricCar{}

从上述代码中我们可以看到使用继承复用产生了很多子类，如果现在又有新的动力源或者新的颜色的话，都要修改源代码，这违背了开闭原则，显然不可取。

3.7.3 案例优化

package com.dfbz.demo07_合成复用原则.优化;


/**
 * @author lscl
 * @version 1.0
 * @intro:
 */
public class Demo01 {
    public static void main(String[] args) {
        Car car=new Car();

        car.color=new Red();
        car.powerType=new ElectricCar();
    }
}

class Car{
    // 颜色
    IColor color;

    // 动力类型
    IPowerType powerType;
}

// 动力类型
interface IPowerType{}

// 电动车
class ElectricCar implements IPowerType{}

// 汽油车
class GasolineCar implements IPowerType{}

// 颜色
interface IColor{}

// 红色车
class Red implements IColor{}

// 黑色车
class Black implements IColor{}

3.8 七大原则总结

• 单一职责原则（Single Responsibility Principle，SRP）：

  • 原则：一个对象只负责单一的职责（一个类只干一件事）。
  • 目的：便于理解，提高代码可读性。

• 接口隔离原则（Interface Segregation Principle，ISP）：

  • 原则：一个类对另一个类（接口）的依赖应该建立在最小接口上（一个接口只干一件事）。
  • 目的：解耦，实现高内聚、低耦合。

• 开闭原则（Open Closed Principle，OCP）：

  • 原则：对扩展开放，对修改关闭
  • 目的：降低维护带来的新风险

• 里氏替换原则（Liskov Substitution Principle，LSP）

  • 原则：子类可以扩展父类功能，但不能修改父类原有功能。
  • 目的：防止重写方法带来的风险

• 依赖倒转原则（Dependence Inversion Principle，DIP）：

  • 原则：使用面向接口编程
  • 目的：利于代码的升级扩展

• 迪米特法则（Law of Demeter，LoD）：

  • 原则：一个类对自己依赖的类知道的越少越好（不该知道的不要知道）
  • 目的：减少代码的臃肿

• 合成复用原则（Composite Reuse Principle，CRP）：

  • 原则：要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。强调白箱复用
  • 目的：降低代码耦合