• 03【设计模式的七大原则】

    三、设计模式的七大原则

    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("行政人员整理资料");
    }

}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18

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

    • 程序员类：
    package com.dfbz.demo01_单一职责原则;

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 行政人员类：
    package com.dfbz.demo01_单一职责原则;

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 相机类：
    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() {

    }

}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 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() {

    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 手机：
    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("拍照~");
    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23

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

    3.2.3 案例优化：

    • 优化：

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

    • 听音乐接口：

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

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 拍照接口：
    package com.dfbz.demo02_接口隔离原则.优化;

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 语音接口：
    package com.dfbz.demo02_接口隔离原则.优化;

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 相机类：
    package com.dfbz.demo02_接口隔离原则.优化;

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 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("拍照~");
    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 手机类：
    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("拍照~");
    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40

    上述代码中违反了开闭原则，不难想象，如果我们还想要连接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");
    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48

    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 {

}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55

    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 {

}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54

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

    • 优化：
    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();
    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52

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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 优化：
    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~");
    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43

    3.7 合成复用原则

    3.7.1 介绍

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

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

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

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

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

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

    • 1
    • 2
    • 3
    • 4
    • 黑箱复用：
    class A{
    public void method(){}
}
class SubA extends A{
    
}
class B{
    private A a;
    public B(A a){}			// 可以传递SubA对象进来
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

    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{}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34

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

    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{}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42

    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）：

      • 原则：要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。强调白箱复用
      • 目的：降低代码耦合
  • 相关阅读:
    Typescript面向对象---下篇
    树莓派安装mariadb
    【力扣周赛】第 362 场周赛（⭐差分&匹配&状态压缩DP&矩阵快速幂优化DP&KMP）
    3.18 悟透了这三条，能让你的小红书运营能力更上一层楼【玩赚小红书】
    基于SIFT图像特征识别的匹配方法比较与实现
    [数据结构] - 顺序表与链表详解
    centos7安装confluence7.16.5
    Arduino程序设计（十三）触摸按键实验（TTP223）
    iwemeta元宇宙:特斯拉CEO马斯克未来10年，卖出1亿特斯拉。你们认为可以吗？
    综述：大规模小目标检测
  • 原文地址：https://blog.csdn.net/Bb15070047748/article/details/125434603