设计模式 - 设计原则-CSDN博客

本文链接：https://blog.csdn.net/qq398470261/article/details/118516972

系列文章目录

创建型模式 - 单例模式（一）
创建型模式 - 工厂模式（二）
创建型模式 - 原型模式（三）
创建型模式 - 建造者模式（四）

结构型模式 - 适配器模式（一）
结构型模式 - 桥接模式（二）
结构型模式 - 装饰器模式（三）
结构型模式 - 组合模式（四）
结构型模式 - 外观模式（五）
结构型模式 - 享元模式（六）
结构型模式 - 代理模式（七）

行为型模式 - 模板方法模式（一）
行为型模式 - 命令模式（二）
行为型模式 - 访问者模式（三）
行为型模式 - 迭代器模式（四）
行为型模式 - 观察者模式（五）
行为型模式 - 中介者模式（六）
行为型模式 - 备忘录模式（七）
行为型模式 - 解释器模式（八）
行为型模式 - 状态模式（九）
行为型模式 - 策略模式（十）
行为型模式 - 责任链模式（十一）

前言

代码地址

一、设计模式的目的

编写软件过程中，程序员面临着来着 耦合性、内聚性、可维护性、可扩展性、重用性、灵活性等多方面的挑战, 设计模式是为了让程序（软件），具有更好的：

代码重用性（即：相同功能的代码，不用多次编写）；
可读性（即：编程规范性，便于其他程序员的阅读和理解）；
可扩展性（即：当需要增加新功能时，非常的方便，成为可维护性）；
可靠性（即：当我们增加新的功能后，对原来的功能没有影响）；
是程序呈现 高内聚 、低耦合的特性;

二、设计模式设计的依据

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础；

单一职责原则；

接口隔离原则；

依赖倒转（倒置）原则；

里氏替换原则；

开闭原则；

迪米特法则；

合成复用原则；

2.1 单一职责原则（Single Responsibility Principle）

为什么要使用单一职责原则？

如果一个类承担的责任过多，就等于把这些职责耦合在一起，一个指责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计；

对类来说的，即一个类应该只负责一项职责。如类A负责两个不同的职责：职责1、职责2。当职责1需要变更而改变A时，可能造成职责2执行错误，多以需要将类A的粒度分解为A1, A2。

单一职责原则注意事项和细节：

降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
提高类的可读性，系统的可维护性；
降低变更引起的风险，修改一个功能时，可以显著降低对其他功能的影响；
通常情况下，我们应遵守单一职责原则，只有逻辑足够简单，才可以在代码级别违反单一职责原则，只有类中方法数量足够少，可以在方法级别保持单一职责原则；

public class SingleResponsibility {
    public static void main(String[] args) {
//        Vehicle vehicle = new Vehicle();
//        vehicle.run("飞机");
//        vehicle.run("高铁");
//        vehicle.run("公交");

//        RoadVehicle roadVehicle = new RoadVehicle();
//        roadVehicle.run("公交");
//        AirVehicle airVehicle = new AirVehicle();
//        airVehicle.run("飞机");
//        WaterVehicle waterVehicle = new WaterVehicle();
//        waterVehicle.run("轮船");

        Vehicle1 vehicle1 = new Vehicle1();
        vehicle1.runAir("飞机");
        vehicle1.runRoad("公交");
        vehicle1.runWater("轮船");

    }
}

/**
 * ----------------- 方式1分析 ----------------------------
 * 问题：这种方式中，run 违反了单一职责，结果不对（飞机在公路上跑这样的结果合适吗？）；
 * 解决：根据交通工具的运行飞方式不同，分为不同的类即可；
 */
class Vehicle{
    public void run(String vehicle){
        System.out.println(String.format("%s,是在公路上跑的...",vehicle ));
    }
}

/**
 * ----------------- 方式2分析 ----------------------------
 * 问题：这种方式中，遵守单一职责，但这样做的改动很大，即将类分解，同时修改调用方式；
 * 解决：修改原始类，改动的代码比较少；
 */
class RoadVehicle{
    public void run(String vehicle){
        System.out.println(String.format("%s,是在公路上跑的...",vehicle ));
    }
}

class AirVehicle{
    public void run(String vehicle){
        System.out.println(String.format("%s,是在天上飞的...",vehicle ));
    }
}

class WaterVehicle{
    public void run(String vehicle){
        System.out.println(String.format("%s,是在水里游的...",vehicle ));
    }
}

/**
 * ----------------- 方式3分析 ----------------------------
 * 这种修改方法没有对原始的类做大的修改，只是增加了方法；
 * 这里虽然没有在类级别上遵守单一职责，但是在方法级别上遵守了单一职责；
 */
class Vehicle1{
    public void runRoad(String vehicle){
        System.out.println(String.format("%s,是在公路上跑的...",vehicle ));
    }

    public void runAir(String vehicle){
        System.out.println(String.format("%s,是在天上飞的...",vehicle ));
    }

    public void runWater(String vehicle){
        System.out.println(String.format("%s,是在水里游的...",vehicle ));
    }
}

2.2 接口隔离原则（Interface Segregation Principle）

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上；

接口隔离原则的含义：我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖他的类去调用。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更加灵活。

2.2.1 接口隔离前

类A通过接口Interface1依赖类B,类C 通过接口Interface1依赖类D，如果Interface1对于类A 和类C 来说不是最小接口，那么类B和类D必须去实现他们不要的方法（类B多余 2、3、4方法，类D多余了1、4方法）；

在这里插入图片描述

package com.dozezz.designpattern.principle.segregation;

/**
 * @Description: 接口隔离原则
 * @Author: dozezz
 * @Date: 2021/7/2 19:17
 * @Version: 1.0
 */
public class Segregation {
    public static void main(String[] args) {

    }
}

interface Interface1{
    void operation1();
    void operation2();
    void operation3();
    void operation4();
}

class ClassB  implements Interface1{

    @Override
    public void operation1() {
        System.out.println(String.format("%s 实现了 %s","Class B", "Interface1 operation1"));
    }

    @Override
    public void operation2() {
        System.out.println(String.format("%s 实现了 %s","Class B", "Interface1 operation2"));
    }

    @Override
    public void operation3() {
        System.out.println(String.format("%s 实现了 %s","Class B", "Interface1 operation3"));
    }

    @Override
    public void operation4() {
        System.out.println(String.format("%s 实现了 %s","Class B", "Interface1 operation4"));
    }
}

class ClassD  implements Interface1{

    @Override
    public void operation1() {
        System.out.println(String.format("%s 实现了 %s","Class D", "Interface1 operation1"));
    }

    @Override
    public void operation2() {
        System.out.println(String.format("%s 实现了 %s","Class D", "Interface1 operation2"));
    }

    @Override
    public void operation3() {
        System.out.println(String.format("%s 实现了 %s","Class D", "Interface1 operation3"));
    }

    @Override
    public void operation4() {
        System.out.println(String.format("%s 实现了 %s","Class D", "Interface1 operation4"));
    }
}

/**
 * 通过接口依赖（使用）B类，只会使用1方法；
 * 问题：如果接口Interface1对于类A和类B来说不是最小接口，那么B和D需要实现他们不需要的方法，比如对于B来说实现了不需要实现的方法2、3、4；
 * 解决： 将接口Interface1拆分为独立的结果接口，类A和类C分别与他们需要的接口建立依赖关系；
 */
class ClassA  {
    public void depend1(Interface1 interface1) {
        interface1.operation1();
    }
}

/**
 * 通过接口依赖（使用）D类，只会使用2、3方法；
 * 问题：如果接口Interface1对于类A和类B来说不是最小接口，那么B和D需要实现他们不需要的方法，比如对于B来说实现了不需要实现的方法1、4；
 * 解决： 将接口Interface1拆分为独立的结果接口，类A和类C分别与他们需要的接口建立依赖关系；
 */
class ClassC  {
    public void depend2(Interface1 interface1) {
        interface1.operation2();
    }

    public void depend3(Interface1 interface1) {
        interface1.operation3();
    }
}

2.2.2 接口隔离后

将接口Interface1 拆分为独立的接口（这里为Interface2、Interface3、Interface4），类G 和类F 分别与他们需要的接口建立依赖关系即可；

在这里插入图片描述

public class Segregation2 {
    public static void main(String[] args) {
        ClassE classE = new ClassE();
        classE.depend1(new ClassG());

        ClassF classF = new ClassF();
        classF.depend2(new ClassH());
        classF.depend3(new ClassH());
    }
}

interface Interface2 {
    void operation1();
}

interface Interface3 {
    void operation2();

    void operation3();
}

interface Interface4 {
    void operation4();
}

class ClassG implements Interface2 {

    @Override
    public void operation1() {
        System.out.println(String.format("%s 实现了 %s", "Class G", "Interface2 operation2"));
    }
}

class ClassH implements Interface3 {

    @Override
    public void operation2() {
        System.out.println(String.format("%s 实现了 %s", "Class H", "Interface3 operation2"));
    }

    @Override
    public void operation3() {
        System.out.println(String.format("%s 实现了 %s", "Class H", "Interface3 operation3"));
    }
}

class ClassE {
    public void depend1(Interface2 interface2) {
        interface2.operation1();
    }
}

class ClassF {
    public void depend2(Interface3 interface3) {
        interface3.operation2();
    }

    public void depend3(Interface3 interface3) {
        interface3.operation3();
    }
}

2.2.3 接口隔离原则总结

采用接口隔离原则对接口进行约束是，应注意：

接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不争的实事，但是如果过小，则会造成接口数量过多，使设计复杂化，所以要适度；
为依赖接口的类定制服务，只暴露给调用的类他需要的方法，他不需要的方法隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系；
提高内聚，减少对外的交互。使接口用最少的方法去完成最多的事情；

2.2.4 单一职责和接口隔离原则区别

很多人觉得接口隔离原则跟单一原则很相似，其实不然。

单一职责原则注重的是职责，而接口隔离原则注重对接口依赖的隔离；
单一职责原则只要是约束类，其次才是接口和方法，他针对的是程序中的实现和细节；而接口隔离原则主要约束接口，主要针对冲向，针对程序整体框架的构建；

2.3 依赖倒转（倒置）原则（Dependence Inversion Principle）

高层模块不应该依赖低层模块，二者都应该依赖其抽象；
抽象不应该依赖细节，细节应该依赖抽象；
依赖倒转（倒置）的中心思想是面向接口编程；
依赖倒置（倒转）原则基于这样的实际理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的框架比以细节为基础的架构要稳定的多，在Java中，抽象指的是接口或抽象类，细节就是具体的实现；
使用接口或抽象类的目的是制定良好的规范，而不涉及任何具体的操作，把展示细节的任务交给他们的实现类去完成；

2.3.1 依赖倒置前

public class DependenceInversion {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}

/**
 * 簡單，比較容易想到但是
 * 问题：如果我們獲取的對象是微信、短信等等，則新增類，同時Perons類也要增加響應的接受方法；
 * 解决： 引入一個抽象的接口，表示接受者，這樣Person 類與接口發生依賴，因為微信，Email、短信等等屬於接受範圍，他們格式實現接口就好了，這就是依賴倒轉（倒置）；
 */
class Person{
    public  void receive(Email email){
        System.out.println(email.getInfo());
    }
}

class Email {
    public  String getInfo(){
        return "電子郵件信息： Hello World ！";
    }
}

2.3.1 依赖倒置后

public class DependenceInversion {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());


        Person1 person1 = new Person1();
        person1.receive(new Email1());
        person1.receive(new Wechat());
    }
}

/**
 * 簡單，比較容易想到但是
 * 问题：如果我們獲取的對象是微信、短信等等，則新增類，同時Perons類也要增加響應的接受方法；
 * 解决： 引入一個抽象的接口，表示接受者，這樣Person 類與接口發生依賴，因為微信，Email、短信等等屬於接受範圍，他們格式實現接口就好了，這就是依賴倒轉（倒置）；
 */
class Person{
    public  void receive(Email email){
        System.out.println(email.getInfo());
    }
}

class Email {
    public  String getInfo(){
        return "電子郵件信息： Hello World ！";
    }
}

interface IReceiver{
    String getInfo();
}

class Person1{
    public  void receive(IReceiver receiver){
        System.out.println(receiver.getInfo());
    }
}

class Email1 implements IReceiver{

    @Override
    public  String getInfo(){
        return "電子郵件信息： Hello World ！";
    }
}

class Wechat implements IReceiver{

    @Override
    public  String getInfo(){
        return "微信信息： Hello World ！";
    }
}

2.3.3 注入方式

//方式1，通过接口
interface IOpenAndClose{
    void open(ITv tv);
}

interface ITv{
 void play();
}

class OpenAndClose implements IOpenAndClose{

    @Override
    public void open(ITv tv) {
        tv.play();
    }
}
//方式2 ，通过构造器
interface IOpenAndClose1{
    void open();
}

interface ITv1{
    void play();
}

class OpenAndClose1 implements IOpenAndClose1{
    public ITv1 iTv1;
    public OpenAndClose1(ITv1 iTv1){
        this.iTv1 = iTv1;
    }

    @Override
    public void open() {
        this.iTv1.play();
    }
}

//方式3 ，通过setter方法传递
interface IOpenAndClose2{
    void open();
    void setITv2(ITv2 itv2);
}

interface ITv2{
    void play();
}

class OpenAndClose2 implements IOpenAndClose2{
    public ITv2 iTv2;

    @Override
    public void open() {
        this.iTv2.play();
    }

    @Override
    public void setITv2(ITv2 itv2) {
        this.iTv2 = iTv2;
    }
}

2.4 里氏替换原则（Liskov Substitution Principle）

OO中继承的思考和说明：

继承包含了这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有子类必须遵守这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系在成破坏；
继承再给程序设计带来便利的同时，也带了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障

那么，在编程中，如何正确的使用继承呢？==>里氏替换原则

如果对每个类型为T1的对象O1,都有类型为T2的对象O2，使得以T1定义的所有程序P的所有对象O1都替换成O2时，程序P的行为没有任何变化，那么类型T2是T1的子类。换句话说，所有引用基类的地方必须能透明地使用其子类对象；
在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法；
里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题；

2.4.1 里氏替换前

public class Substitution {
    public static void main(String[] args) {
        A a = new A();
        System.out.println(String.format("A: %d - %d = %d", 11, 3, a.func1(11,3)));
        System.out.println(String.format("A: %d - %d = %d", 1, 8, a.func1(1,8)));
        System.out.println("------------------------ 分割线 --------------------------------");
        B b = new B();
        System.out.println(String.format("B: %d - %d = %d", 11, 3, b.func1(11,3)));
        System.out.println(String.format("B: %d - %d = %d", 1, 8, b.func1(1,8)));
        System.out.println(String.format("B: %d + %d + %d = %d", 11, 3,9, b.func2(11,3)));
    }
}

class A{
    public int func1(int num1,int num2){
        return num1 - num2;
    }
}

class B extends A{
    public int func1(int num1, int num2) {
        return num1 + num2;
    }

    public int func2(int num1, int num2) {
        return func1(num1, num2) +10;
    }
}

问题：原来正常运行的相减功能发生了错误，原因就是类B无意中重写了父类的方法，造成原有功能出现错误。
在实际的编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来简单，但整个继承体系的复用性会比较差。
特别是运行多态比较频繁的时候；
解决：原有的基类和子类继承更通俗的基类，原有的继承关系去掉，采用依赖，组合，聚合等关系替代；

2.4.1 里氏替换后

public class Substitution {
    public static void main(String[] args) {
        D d = new D();
        //因为D类（B类）不在继承A类，因此调用者不再认为是求减法，调用完成的功能更加明确；
        System.out.println(String.format("D: %d - %d = %d", 11, 3, d.func1(11,3)));
        System.out.println(String.format("D: %d + %d = %d", 1, 8, d.func1(1,8)));

        //如果还想使用A中的方法（C类），使用组合仍然可以使用A(C)中的方法；
        System.out.println(String.format("D: %d - %d + %d = %d", 11, 3,9, d.func3(11,3)));
    }
}

//创建一个更加基础的基类
class Base{
//把更加基础的方法和成员写到Base类中；
}

class C extends  Base{
    public int func1(int num1,int num2){
        return num1 - num2;
    }
}

class D extends Base{

    private C c = new C();

    public int func1(int num1, int num2) {
        return num1 + num2;
    }

    public int func2(int num1, int num2) {
        return func1(num1, num2) +10;
    }
    // 仍想使用C中的方法
    public int func3(int num1, int num2) {
        return c.func1(num1,num2) + 10;
    }
}

2.5 开闭原则（Open Close Principle）

开闭原则是编程中最基础、最重要的设计原则；
一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建的框架，用实现细节扩展；
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化；
编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则；

2.5.1 开闭原则使用前

public class OpenClose {
    public static void main(String[] args) {
        //优点：比较好理解，简单易操作
        //缺点： 违反了设计模式的OCP原则，即对扩展开放（提供方），对修改关闭（使用方），即当我们给类增加新功能的时候，尽量不修改代码或者尽可能的少修改代码！
        //      比如我们这时要新增一个图形Triangle种类，我们需要做好多修改！
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawRectangle(new Rectangle());
        graphicEditor.drawCircle(new Circle());
    }
}
class GraphicEditor{
    public void drawShape(Shape shape){
        if(shape.m_type == 1){
            drawRectangle(shape);
        }else if(shape.m_type == 2){
            drawCircle(shape);
        }
//        else if(shape.m_type == 3){
//            drawTriangle(shape);
//        }
    }

//    private void drawTriangle(Shape shape) {
//        System.out.println("三角形");
//    }

    public void drawRectangle(Shape shape){
        System.out.println("矩形");
    }
    public void drawCircle(Shape shape ){
        System.out.println("圆形");
    }
}

优点：比较好理解，简单易操作
缺点：违反了设计模式的OCP原则，即对扩展开放（提供方），对修改关闭（使用方），即当我们给类增加新功能的时候，尽量不修改代码或者尽可能的少修改代码！
比如我们这时要新增一个图形Triangle种类，我们需要做好多修改！

2.5.2 开闭原则使用后

class GraphicEditor1{
    public void drawShape(Shape1 shape1){
        shape1.draw();
    }

}

abstract  class Shape1{
    int m_type;
    public abstract void draw();
}

class Rectangle1 extends Shape1{
    Rectangle1(){
        super.m_type = 1;
    }

    @Override
    public void draw() {
        System.out.println("矩形");
    }
}
class Circle1 extends Shape1{
    Circle1(){
        super.m_type = 2;
    }

    @Override
    public void draw() {
        System.out.println("圆形");
    }
}

2.6 迪米特法则（Law Of Demeter）

一个对象应该对其他对象保持最小的了解；
类与类关系越密切，耦合度越大；
迪米特法则也叫最小知道原则，即一个类对自己依赖的类知道的越少越好，也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部，对外除了提供公共的方法，不对外泄漏任何信息；
迪米特法则还有个更简单的定义：只与直接的朋友通信；
直接的朋友：每个对象都会与其他对象由耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接朋友，而出现在局部变量中的类不是直接朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部；

2.6.1 迪米特法则使用前

public class Demeter {
    public static void main(String[] args) {
        CollegeManager collegeManager = new CollegeManager();
        SchoolManager schoolManager = new SchoolManager();
        schoolManager.printAllEmployee(collegeManager);
    }
}
class Employee{
    private String id ;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

class CollegeEmployee{
    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

class CollegeManager{
    public List<CollegeEmployee> getAllEmployee(){
        List<CollegeEmployee> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            CollegeEmployee collegeEmployee = new CollegeEmployee();
            collegeEmployee.setId(String.format("CollegeManager-ID: %d",i+1));
            list.add(collegeEmployee);
        }
        return  list;
    }
}
//类的直接朋友有Employee/CollegeManager
//CollegeEmployee不是直接朋友，这样违背了迪米特法则（出现成员变量，方法参数，方法返回值中的类为直接朋友）
class SchoolManager{
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            Employee employee = new  Employee();
            employee.setId(String.format("SchoolManager-ID: %d",i+1));
            list.add(employee);
        }
        return  list;
    }

    void printAllEmployee(CollegeManager collegeManager){
        //分析问题：
        //1、这里的 CollegeEmployee 不是 SchoolManager 的直接朋友
        //2、CollegeEmployee 是以局部变量方式出现在 SchoolManager 中
        //3、违反了迪米特法则，按照迪米特法则应该避免出现这样非直接朋友关系的耦合
        List<CollegeEmployee> employees = collegeManager.getAllEmployee();
        employees.stream().map(CollegeEmployee::getId).forEach(System.out::println);
    }
}

2.6.1 迪米特法则使用后

public class Demeter {
    public static void main(String[] args) {
        SchoolManager schoolManager = new SchoolManager();
        schoolManager.printAllEmployee(new CollegeManager());
    }
}
class Employee{
    private String id ;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

class CollegeEmployee{
    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

class CollegeManager{
    public List<CollegeEmployee> getAllEmployee(){
        List<CollegeEmployee> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            CollegeEmployee collegeEmployee = new CollegeEmployee();
            collegeEmployee.setId(String.format("CollegeManager-ID: %d",i+1));
            list.add(collegeEmployee);
        }
        return  list;
    }
//改进后
    public void printAllEmployee() {
        getAllEmployee().stream().map(CollegeEmployee::getId).forEach(System.out::println);
    }
}
//类的直接朋友有Employee/CollegeManager
//CollegeEmployee不是直接朋友，这样违背了迪米特法则（出现成员变量，方法参数，方法返回值中的类为直接朋友）
class SchoolManager{
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            Employee employee = new  Employee();
            employee.setId(String.format("SchoolManager-ID: %d",i+1));
            list.add(employee);
        }
        return  list;
    }

    void printAllEmployee(CollegeManager collegeManager){
//        分析问题：
//        1、这里的 CollegeEmployee 不是 SchoolManager 的直接朋友
//        2、CollegeEmployee 是以局部变量方式出现在 SchoolManager 中
//        3、违反了迪米特法则，按照迪米特法则应该避免出现这样非直接朋友关系的耦合
//        List<CollegeEmployee> employees = collegeManager.getAllEmployee();
//        employees.stream().map(CollegeEmployee::getId).forEach(System.out::println);

//        改进：
//        1、将输出员工信息的方法，封装到 CollegeManager
        collegeManager.printAllEmployee();
    }
}

迪米特法则注意事项和细节：

迪米特法则的核心是降低类之间的耦合；
但是注意：由于每个类都减少不必要的依赖，因此迪米特法则只是要求降低类间（对象间）耦合关系，并不是要求完全没有依赖关系；

2.7 合成复用原则

原则是尽量使用合成、聚合的方式，而不是使用继承；

三、设计模式分类

在这里插入图片描述

3.1 创建型模式

创建型模式关注点“怎么创建对象？”，

将对象的创建与使用分类`;
降低系统的耦合度：
使用者无需关注对象创建细节；

创建型模式分类：

单例模式（Singleton Pattern）：一个单一的类，负责创建自己的对象，同时确保系统中只有单个对象被创建；
抽象工厂模式：对象的创建由相关的工程来完成；
原型模式（Prototype Pattern）：用于床阿金重复的对象，同时又能保证性能；
建造者模式（Builder Pattern）：对象的创建由相关的工程来完成；
工厂模式：对象的创建由相关的工程来完成；；

3.2 结构型模式

结构型模式关注点“怎么组合对象或者类”。根据 合成复用原则，大部分结构型模式都是对象结构模式；

类结构型模式：关心类的组合，由多个类可以组合成一个更大的（继承）；
对象结构模式：关系类与对象的组合，通过使用 关联关系 在一个类中定义另一个类的实例对象（组合）；

创建型模式分类：

适配器模式（Adapter Pattern）:两个不兼容接口之间适配的桥梁；
桥接模式（Bridge Pattern）: 相同功能抽象化与实现化解耦，抽象与实现可以独立升级；
装饰器模式（Facade Pattern）: 向一个现有的对象添加新功能，同时又不改变其结构；
组合模式（Composite Pattern）；相似对象进行组合，形成树形结构；
外观模式（Facade Pattern）：向现有的系统添加一个接口，客户端访问此接口来隐藏系统的复杂性；
享元模式（Flyweight Pattern）：尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象；
代理模式（Proxy Pattern）：一个类代表另一个类的功能；

3.3 行为型模式

行为型模式关注点怎么运行对象或类。

行为模式用于描述程序在运行时复杂的流程控制；
描述多个类或对象之间怎么相互协作共同完成单个对象都无法单独完成任务，它涉及算法与对象间职责的分配；
行为模式分为类行为模式和对象行为模式,根据 合成复用原则，大部分xi行为型模式都是对象行为模式；

类行为模式：采用继承机制来在类间分派行为；
对象行为模式：采用组合或聚合在对象间分派行为；

行为型模式分类：

模板方法模式（Templete Pattern）：父类定义算法骨架，某些实现放在子类；
命令模式（Command Pattern）：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分隔开；
访问者模式（Visitor Pattern）：分离对象结构，与元素的执行算法；
迭代器模式（Iterator Pattern）：定义组合数据的遍历规则；
观察者模式（Observer Pattern）：维护多个观察者依赖，状态变化通知所有观察者；
中介者模式（Mediator Pattern）：取消类或对象的直接调用关系，使用中介者维护；
备忘录模式（Memento Pattern）：把核心信息抽取出来，可以进行保存；
解释器模式（Interpreter Pattern）：定义语法解析规则；
状态模式（State Pattern）：每种状态独立封装，不同状态内部封装了不同行为；
策略模式（Strategy Pattern）：每种算法独立封装，根据不同情况使用不同算法策略；
责任链模式（Chain Of Responsibility Pattern）：所有处理者封装为链式结构，依次调用；

四、参考文献

https://www.bilibili.com/video/BV1G4411c7N4?p=23&spm_id_from=pageDriver
https://baiyp.ren/JAVA%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E7%9A%84%E5%85%AD%E5%A4%A7%E5%8E%9F%E5%88%99.html