设计模式学习心得之前置知识 UML图看法与六大原则（下）-阿里云开发者社区

设计模式学习心得之前置知识 UML图看法与六大原则（上）：https://developer.aliyun.com/article/1548552

依赖倒转原则

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

下面看一个例子来理解依赖倒转原则

【例】组装电脑

现要组装一台电脑，需要配件cpu，硬盘，内存条。只有这些配置都有了，计算机才能正常的运行。选择cpu有很多选择，如Intel，AMD等，硬盘可以选择希捷，西数等，内存条可以选择金士顿，海盗船等。

类图如下：

代码如下：

希捷硬盘类（XiJieHardDisk）:

public class XiJieHardDisk  {
    public void save(String data) {
        System.out.println("使用希捷硬盘存储数据" + data);
    }
    public String get() {
        System.out.println("使用希捷希捷硬盘取数据");
        return "数据";
    }
}

Intel处理器（IntelCpu）：

public class IntelCpu {
    public void run() {
        System.out.println("使用Intel处理器");
    }
}

金士顿内存条（KingstonMemory）：

public class KingstonMemory  {
    public void save() {
        System.out.println("使用金士顿作为内存条");
    }
}

电脑（Computer）：

public class Computer {
    private XiJieHardDisk hardDisk;
    private IntelCpu cpu;
    private KingstonMemory memory;
    public IntelCpu getCpu() {
        return cpu;
    }
    public void setCpu(IntelCpu cpu) {
        this.cpu = cpu;
    }
    public KingstonMemory getMemory() {
        return memory;
    }
    public void setMemory(KingstonMemory memory) {
        this.memory = memory;
    }
    public XiJieHardDisk getHardDisk() {
        return hardDisk;
    }
    public void setHardDisk(XiJieHardDisk hardDisk) {
        this.hardDisk = hardDisk;
    }
    public void run() {
        System.out.println("计算机工作");
        cpu.run();
        memory.save();
        String data = hardDisk.get();
        System.out.println("从硬盘中获取的数据为：" + data);
    }
}

测试类（TestComputer）：

测试类用来组装电脑。

public class TestComputer {
    public static void main(String[] args) {
        Computer computer = new Computer();
        computer.setHardDisk(new XiJieHardDisk());
        computer.setCpu(new IntelCpu());
        computer.setMemory(new KingstonMemory());
        computer.run();
    }
}

上面代码可以看到已经组装了一台电脑，但是似乎组装的电脑的cpu只能是Intel的，内存条只能是金士顿的，硬盘只能是希捷的，这对用户肯定是不友好的，用户有了机箱肯定是想按照自己的喜好，选择自己喜欢的配件。

根据依赖倒转原则进行改进：

代码我们只需要修改Computer类，让Computer类依赖抽象（各个配件的接口），而不是依赖于各个组件具体的实现类。

类图如下：

电脑（Computer）：

public class Computer {
    private HardDisk hardDisk;
    private Cpu cpu;
    private Memory memory;
    public HardDisk getHardDisk() {
        return hardDisk;
    }
    public void setHardDisk(HardDisk hardDisk) {
        this.hardDisk = hardDisk;
    }
    public Cpu getCpu() {
        return cpu;
    }
    public void setCpu(Cpu cpu) {
        this.cpu = cpu;
    }
    public Memory getMemory() {
        return memory;
    }
    public void setMemory(Memory memory) {
        this.memory = memory;
    }
    public void run() {
        System.out.println("计算机工作");
    }
}

面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。

感悟与代码

其实这本身很符合多态

package com.priniciples.DependencyInversion.after;
/**
 * @Description
 * @Author Qiu
 * @Date 2024/4/19
 */
public class ComputerDome {
    public static void main(String[] args) {
        // 创建计算机对象
        Computer computer = new Computer();
        // HardDisk hardDisk = new XiJieHardDisk();
        //组装电脑 我这里是使用强制转换 因为 也可像上面这样向上转型创建对象
        computer.setHardDisk((HardDisk) new XiJieHardDisk());
        computer.setCpu((Cpu) new IntelCpu());
        computer.setMemory((Memory) new KingstonMemory());
        computer.run();
    }
}

package com.priniciples.DependencyInversion.after;
/**
 * @Description
 * @Author Qiu
 * @Date 2024/4/19
 */
public interface Cpu {
    public void run();
}
package com.priniciples.DependencyInversion.after;
/**
 * @Description
 * @Author Qiu
 * @Date 2024/4/19
 */
public interface HardDisk {
    public void save(String data);
    public String get();
}
package com.priniciples.DependencyInversion.after;
/**
 * @Description
 * @Author Qiu
 * @Date 2024/4/19
 */
public interface Memory {
    public void save();
}

在这个例子中高层模块是计算机是由多个部件组装而成的，底层模块是具体的厂家的东西，他们之间不相互链接，而是使用接口连接起来，高层模块使用的是cpu这个概念，而不是具体的实例，底层模块是对cpu这个概念的具体实现
开闭原则关注于如何设计软件实体使其在不修改现有代码的情况下进行扩展，而依赖倒置原则关注于如何设计模块之间的依赖关系，使得高层模块不依赖于低层模块的具体实现细节
依赖倒转主要靠继承、实现关系来实现，很经典的面向接口编程

接口隔离原则

客户端不应该被迫依赖于它不使用的方法；一个类对另一个类的依赖应该建立在最小的接口上。

下面看一个例子来理解接口隔离原则

【例】安全门案例

我们需要创建一个黑马品牌的安全门，该安全门具有防火、防水、防盗的功能。可以将防火，防水，防盗功能提取成一个接口，形成一套规范。类图如下：

上面的设计我们发现了它存在的问题，黑马品牌的安全门具有防盗，防水，防火的功能。现在如果我们还需要再创建一个传智品牌的安全门，而该安全门只具有防盗、防水功能呢？很显然如果实现SafetyDoor接口就违背了接口隔离原则，那么我们如何进行修改呢？看如下类图：

代码如下：

AntiTheft（接口）：

public interface AntiTheft {
    void antiTheft();
}

Fireproof（接口）：

public interface Fireproof {
    void fireproof();
}

Waterproof（接口）：

public interface Waterproof {
    void waterproof();
}

HeiMaSafetyDoor（类）：

public class HeiMaSafetyDoor implements AntiTheft,Fireproof,Waterproof {
    public void antiTheft() {
        System.out.println("防盗");
    }
    public void fireproof() {
        System.out.println("防火");
    }
    public void waterproof() {
        System.out.println("防水");
    }
}

ItcastSafetyDoor（类）：

public class ItcastSafetyDoor implements AntiTheft,Fireproof {
    public void antiTheft() {
        System.out.println("防盗");
    }
    public void fireproof() {
        System.out.println("防火");
    }
}

感悟与代码

没什么好说的这个，就是一个接口只有一个功能，防止要一个香蕉却出现一片香蕉林的情况
主要是实现关系

迪米特法则

迪米特法则又叫最少知识原则。

只和你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。

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

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

下面看一个例子来理解迪米特法则

【例】明星与经纪人的关系实例

明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如和粉丝的见面会，和媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则。

类图如下：

代码如下：

明星类（Star）

public class Star {
    private String name;
    public Star(String name) {
        this.name=name;
    }
    public String getName() {
        return name;
    }
}

粉丝类（Fans）

public class Fans {
    private String name;
    public Fans(String name) {
        this.name=name;
    }
    public String getName() {
        return name;
    }
}

媒体公司类（Company）

public class Company {
    private String name;
    public Company(String name) {
        this.name=name;
    }
    public String getName() {
        return name;
    }
}

经纪人类（Agent）

public class Agent {
    private Star star;
    private Fans fans;
    private Company company;
    public void setStar(Star star) {
        this.star = star;
    }
    public void setFans(Fans fans) {
        this.fans = fans;
    }
    public void setCompany(Company company) {
        this.company = company;
    }
    public void meeting() {
        System.out.println(fans.getName() + "与明星" + star.getName() + "见面了。");
    }
    public void business() {
        System.out.println(company.getName() + "与明星" + star.getName() + "洽淡业务。");
    }
}

感悟与代码

请先自己实现复制粘贴下代码，然后再看我写的见解

package com.priniciples.LawOfDemeter;
/**
 * @Description
 * @Author Qiu
 * @Date 2024/4/19
 */
public class Client {
    public static void main(String[] args) {
        Agent agent=new Agent();
        Fans fans = new Fans("粉丝一");
        Star star = new Star("Qiu");
        Company company=new Company("公司1");
        // 由经纪人 也就是Agent方法来链接 粉丝公司明星
        agent.setFans(fans);
        agent.setStar(star);
        agent.setCompany(company);
        agent.meeting();//和粉丝见面
        agent.business();//和媒体公司洽谈业务
    }
}

如果没有Agent类，那么明星就得有两个方法来对接粉丝和媒体公司，而媒体公司、粉丝都是如此。不然只能调用明星类完成功能
有了经纪人类后，只需要在经纪人类中定义中实现就可以了，这种情况在有交集的类越多就越能体现出来其价值
主要是聚合、依赖关系

合成复用原则

合成复用原则是指：尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

通常类的复用分为继承复用和合成复用两种。

继承复用虽然有简单和易实现的优点，但它也存在以下缺点：

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

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

它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
对象间的耦合度低。可以在类的成员位置声明抽象。
复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

下面看一个例子来理解合成复用原则

【例】汽车分类管理程序

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

从上面类图我们可以看到使用继承复用产生了很多子类，如果现在又有新的动力源或者新的颜色的话，就需要再定义新的类。我们试着将继承复用改为聚合复用看一下。

感悟与代码

这个时候再多一种动力源，那么继承复用会多三个类、新动力源、红色新动力、白色新动力
而合成复用只会多一个类，新动力源类
这其实是个数学问题，其核心思想就是对已经封装的再进行抽取相同类的东西封装

在以下缺点：

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

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

它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
对象间的耦合度低。可以在类的成员位置声明抽象。
复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

下面看一个例子来理解合成复用原则

【例】汽车分类管理程序

感悟与代码

这个时候再多一种动力源，那么继承复用会多三个类、新动力源、红色新动力、白色新动力
而合成复用只会多一个类，新动力源类
这其实是个数学问题，其核心思想就是对已经封装的再进行抽取相同类的东西封装

设计模式学习心得之前置知识 UML图看法与六大原则（下）

依赖倒转原则

感悟与代码

接口隔离原则

感悟与代码

迪米特法则

感悟与代码

合成复用原则

感悟与代码

感悟与代码

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

设计模式学习心得之前置知识 UML图看法与六大原则（下）

依赖倒转原则

感悟与代码

接口隔离原则

感悟与代码

迪米特法则

感悟与代码

合成复用原则

感悟与代码

感悟与代码

热门文章

最新文章

相关课程

相关电子书

相关实验场景