三、设计模式的七大原则

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

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

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

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

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

白箱复用：

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

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

设计模式的七大原则（设计模式必修课）

三、设计模式的七大原则

3.1 单一职责原则

3.1.1 介绍

3.1.2 应用示例

3.2 接口隔离原则

3.2.1 介绍

3.2.2 应用示例：

3.2.3 案例优化：

3.3 开闭原则

3.3.1 介绍

3.3.2 应用示例

3.3.3 案例优化

3.3 里氏替换原则

3.3.1 介绍

3.3.2 应用示例

3.3.3 案例优化

3.4 依赖倒转原则

3.4.1 介绍

3.4.2 应用示例

3.4.3 案例优化

3.6 迪米特法则

3.6.1 介绍

3.6.2 应用示例

1）案例1

2）案例2

3.7 合成复用原则

3.7.1 介绍

3.7.2 应用示例

3.7.3 案例优化

3.8 七大原则总结

热门文章

最新文章

相关课程

相关电子书