李建忠讲23种设计模式笔记-上

前两天在B站看了李建忠老师讲23种设计模式的系列视频，收获颇丰。设计模式是前人的智慧和经验的总结，需要我们反复地学习、在实践中体会其蕴含的设计原则和设计思想。李老师按照封装变化将23种设计模式分成组件协作、单一职责、对象创建、对象性能、接口隔离、状态变化、数据结构、行为变化和领域问题九类，为我们理解设计模式提供了新角度。现将李老师的讲课内容整理出来，与大家分享～内容较长，分为上下两篇，本文是第一篇

第一讲：设计模式简介

什么是设计模式

“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。
——Christopher Alexander

如何解决复杂性

1.分解
即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。分解是人们面对复杂性时的常见做法
2.抽象
由于不能掌握全部的复杂对象，从而选择忽视它的非本质细节而去处理泛化和理想化的对象模型。抽象是处理复杂性的更高层次的解决方案，也是通用的技术

软件设计的目标：复用

第二讲：面向对象原则

变化是复用的天敌，面向对象设计的最大优势在于 “抵御变化” ！

重新理解面向对象

1. 隔离变化：宏观层面看，面向对象的构建方式更能适应软件变化，能将变化所带来的影响减到最小
2. 各司其职：微观层面看，面向对象强调各个类的“责任”。由于需求变化导致的新增类型不应该影响原来类型的实现，这是所谓的各负其责
3. 对象含义：语言层面看，对象封装了代码和数据；规格层面看，对象是一系列可被使用的公共接口；概念层面看，对象是某种拥有责任的抽象

面向对象设计八大原则

依赖倒置原则（DIP）

• 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)
• 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)

开放封闭原则（OCP）

• 对扩展开放，对更改封闭
• 类模块应该是可扩展的，但是不可修改

单一职责原则（SRP）

• 一个类应该仅有一个引起它变化的原因
• 变化的方向隐含着类的责任

Liskov 替换原则（LSP）

• 子类必须能够替换它们的基类(IS-A)
• 继承表达类型抽象

接口隔离原则（ISP）

• 不应该强迫客户程序依赖它们不用的方法
• 接口应该小而完备

优先使用对象组合，而不是类继承

• 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”
• 继承在某种程度上破坏了封装性，子类父类耦合度高
• 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低
  封装变化点
• 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合

针对接口编程，而不是针对实现编程

• 不将变量类型声明为某个特定的具体类，而是声明为某个接口
• 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口
• 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案

产业强盛的标志：接口标准化！

将设计原则提升为设计经验

1. 设计习语 Design Idioms ：描述与特定编程语言相关的底层模式，技巧和习惯用法
2. 设计模式 Design Patterns ：主要描述“类与相互通信的对象之间的组织关系”，包括它们的角色、职责、协作方式等方面
3. 架构模式 Architectural Patterns ：描述系统中与基本结构组织关系密切的高层模式，包括子系统划分、职责，以及如何组织它们之间关系的规则

设计模式分类

从目的来看：

• 创建型模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体实现引来的冲击
• 结构型模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击
• 行为型模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击

从范围来看

• 类模式处理类与子类的静态关系（更偏向于继承方案）
• 对象模式处理对象间的动态关系（更偏向于对象组合方案）

从封装变化角度进行分类

• 组件协作：Template Method、Strategy、Observer/Event
• 单一职责：Decorator、Bridge
• 对象创建：Factory Method、Abstract Factory、Prototype、Builder
• 对象性能：Singleton、Flyweight
• 接口隔离：Facade、Proxy、Mediator、Adapter
• 状态变化：Memento、State
• 数据结构：Composite、Iterator、Chain of Responsibility
• 行为变化：Command、Visitor
• 领域问题：Interpreter

重构获得模式

• 面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指的是那些可以满足“应对变化、提高复用”的设计
• 现代软件设计的特征是“需求的频繁变化”。设计模式的要点是“寻找变化点，然后在变化点应用设计模式，从而更好地应对需求的变化”。“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要
• 设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns（重构中获得模式）”是目前普遍公认的使用设计模式的最好方法

推荐图书：《重构----改善既有代码的设计》、《重构与模式（Refactoring to PaPatterns）》

重构关键技法

1. 静态 -> 动态（静态绑定 -> 动态绑定）
2. 早绑定 -> 晚绑定
3. 继承 -> 组合
4. 编译时依赖 -> 运行时依赖
5. 紧耦合 -> 松耦合

“组件协作”模式

现代软件发展带来的第一个结果是“框架与应用程序的划分” ，“组件协作” 模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式

• 典型模式：
  – Template Method、
  – Strategy、
  – Observer / Event

第三讲：设计模式之Template Method 模版方法模式

动机

• 在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现
• 如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？

定义
定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template Method 使得子类可以不改变（复用）一个算法的结构即可重定义（override 重写）该算法的某些特定步骤

结构

要点总结

• Template Method 模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（抽象方法的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构
• 处理可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用
• 在具体实现方面，被Template Method 调用的抽象方法可以有实现 ，也可以没有任何实现，但一般推荐将它们设置为protected 方法

第四讲：设计模式之 Strategy 策略模式

动机

• 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候不支持使用的算法也是一个性能负担
• 如何在运行时根据需要透明地更改对象的算法，将算法与对象本身解耦，从而避免上述的问题？

定义
定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展、子类化）
结构

要点总结

• Strategy 及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换
• Strategy 模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要 Strategy 模式
• 如果Strategy 对象没有实例变量，那么各个上下文可以共享同一个Strategy 对象，从而节省对象开销

第五讲：设计模式之Observer 观察者模式

动机

• 在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” - 一个对象（目标对象）的状态改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化
• 使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系，从而实现软件体系结构的松耦合

定义
定义对象间的一种一对多（变化）的依赖关系，以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都能得到通知并自动更新

结构

要点总结

• 使用面向对象的抽象，Observer模式使得我们可以独立地改变目标于观察者，从而使二者之间的依赖关系达到松耦合
• 目标发出通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播
• 观察者会自己决定是否需要订阅通知，目标对象对此一无所知
• Observer 模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分

“单一职责”模式

在软件组件的设计中，如果责任划分不清晰，使得继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任

典型模式

• Decorator
• Bridge

第六讲：设计模式之Decorator 装饰模式

动机

• 在某些情况下，我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀
• 如何使“对象功能的扩展”能够根据需要来动态地实现，同时避免“扩展功能的增多”带来的子类膨问题，从而使得任何“功能扩展变化”所导致的影响降到最低？

定义
动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator 模式比生成子类（继承）更为灵活（消除重复代码 & 减少子类个数）

结构

要点总结

• 通过采用组合而非继承的手法，Decorator 模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了使用继承带来的“灵活性差”和“多子类衍生问题”
• Decorator 类在接口上表现为 is-a Component 的继承关系，即 Decorator 类继承了Component 类所具有的接口，但在实现上又表现为 has-a Component 的组合关系，即Decorator 类又使用了另外一个Component 类
• Decorator 模式的目的并非解决“多子类衍生的多继承”问题，Decorator 模式应用的要点在于解决“ 主体类在多个方向上的扩展功能 ” — 是为”装饰“的含义

如果看到一个类继承自一个父类，同时组合了一个相同父类的成员对象，可以怀疑使用了 Decorator 设计模式

第七讲：设计模式之 Bridge 桥模式

动机

• 由于某些类型的固有的实现逻辑，使得它们具有两个乃至多个维度的变化
• 如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？

定义
将抽象部分（业务功能）与实现部分（平台实现）分离，使它们都可以独立地变化

结构

要点总结

• Bridge 模式使用“ 对象间的组合关系 ”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自维度变化，即“子类化”它们
• Bridge 模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge 模式是比多继承方案更好的解决方法
• Bridge 模式的应用一般在“ 两个非常强的变化维度 ”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式

“对象创建” 模式

• 通过“对象创建” 模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作

典型模式

• Factory Method
• Abstract Factory
• Prototype
• Builder

第八讲：设计模式之 Factory Method 工厂方法模式

动机

• 在软件系统中，经常面临着创建对象的工作。由于需求的变化，需要创建的对象的具体类型经常变化
• 如何应对这种变化，如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？

定义
定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使得一个类的实例化延迟（目的：解耦；手段：抽象方法）到子类

结构

要点总结

• Factory Method 模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱
• Factory Method 模式通过面向对象的手法（多态），将具体对象的创建工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系
• Factory Method 模式解决“单个对象” 的需求变化，缺点在于要求 创建方法/参数 相同

第九讲：设计模式之 Abstract Factory 抽象工厂模式

动机

• 在软件系统中，经常面临着“ 一系列相互依赖的对象 ”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作
• 如何应对这种变化，如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？

定义
提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类

结构

要点总结

• 如果没有应对“多系列对象构建”的需求变化，则没有必要使用 Abstract Factory 模式，这时候使用简单的工厂完全可以
• “ 系列对象 ”指的是在某一特定系列下的对象之间有相互依赖或作用的关系，不同系列的对象之间不能互相依赖
• Abstract Factory 模式主要在于应对“ 新系列 ”的需求变动。其缺点在于难以应对“新对象”的需求变动

第十讲：设计模式之 Prototype 原型模式

动机

• 在软件系统中，经常面临着“ 某些结构复杂的对象 ”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口
• 如何应对这种变化，如何向“客户程序（使用这些对象的程序）”隔离出“这些易变对象”，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变？

定义
使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象

结构

要点总结

• Prototype 模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”
• Prototype 模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象 — 所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方 clone
• Prototype 模式中的 clone 方法可以利用某些框架中的序列化来实现深拷贝

第十一讲：设计模式之 Builder 构建器模式

动机

• 在软件系统中，有时候面临着“一个复杂对象” 的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定
• 如何应对这种变化，如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保证系统中的“稳定构建算法”不随着需求改变而改变？

定义
将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）

结构

要点总结

• Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“ 分步骤 ”是一个稳定的算法，而复杂对象的各个部分则经常变化
• 变化点在哪里，封装就在哪里 — Builder 模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动
• 在Builder 模式中，要注意不同语言中构造器内调用抽象方法的差别

对象性能

面向对象很好地解决了“抽象”的问题，但是不可避免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理

典型模式

• Singleton
• Flyweight(享元模式)

第十二讲：设计模式之 Singleton 单例模式

动机

• 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率
• 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？
• 这应该是类设计者的责任，而不是使用者的责任

定义
保证一个类仅有一个实例，并提供一个该实例的全局访问点

结构

要点总结

• Singleton 模式中的实例构造器可以设置为protected 以允许子类派生
• Singleton 模式一般不要支持拷贝构造方法和 clone 接口，因为这有可能导致多个对象实例，违背 Singleton 模式的初衷
• 如何实现多线程环境下安全的 Singleton ？注意对双检查锁的正确实现

第十三讲：设计模式之 Flyweight 享元模式

动机

• 在软件系统中，采用纯粹对象方案的问题在于系统中会很快充斥大量细粒度的对象，从而带来很高的运行时代价 — 主要指内存需求方面的代价
• 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式进行操作？

定义
运用共享技术有效地支持大量细粒度的对象

结构

要点总结

• 面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight 主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题
• Flyweight 采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态（最好状态不可更改）的处理
• 对象的数量太大从而导致对象内存开销加大 — 什么样的数量才算大？这需要我们仔细根据具体应用情况进行评估，而不能凭空臆断

下篇👉：https://blog.csdn.net/mg2flyingff/article/details/105876810