简单工厂模式
- 定义：由一个工厂对象决定创建出哪一种产品类的实例
- 类型：创建型，但不属于GOF23种设计模式
- 适用场景：
- 工厂类负责创建的对象比较少
- 客户端（应用层）只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心
- 优点：只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节
- 缺点：工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，违背开闭原则
image
工厂方法模式*（带星号为常用设计模式）
- 定义：定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，工厂方法让类的实例化推迟到子类中进行
- 类型：创建类
- 适用场景：
- 创建对象需要大量重复的代码
- 客户端（应用层）不依赖于产品类实例如何创建、实现等细节
- 一个类通过其子类来指定创建哪个对象
- 同一产品等级的类变化较大（横向变化，增加同一产品等级的类不修改原来的代码）
- 优点：
- 用户只需要关心所需产品对应的工厂，无须关心创建细节
- 加入新产品符合开闭原则，提高可扩展性
- 缺点：
- 类的个数容易过多，增加系统复杂度
- 增加了系统的抽象性和理解难度
image
抽象工厂模式*
- 定义：抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类
- 类型：创建型
- 适用场景：
- 客户端（应用层）不依赖于产品类实例如何被创建、实现等细节
- 强调一系列相关的产品对象（属于同一个产品族）一起使用创建对象需要大量重复的代码
- 提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现
- 产品族变化较大（纵向变化，增加产品族不修改原来的代码）
- 优点：
- 具体产品在应用层代码隔离，无须关心创建细节
- 将一个系列的产品族统一到一起创建
- 缺点：
- 视定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口
- 增加了系统的抽象性和理解难度
image
建造者模式*
- 定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
- 用户只需指定需要建造的类型就可以得到它们，建造过程及细节不需要知道
- 类型：创建型
- 适用场景：
- 如果一个对象有非常复杂的内部结构（很多属性）
- 想把复杂对象的创建和使用分离
- 优点：
- 封装性好，创建和使用分离
- 扩展性好、建造类之间独立、一定程度上解耦
- 缺点：
- 产生多余的Builder对象
- 产品内部发生变化，建造者都要修改，成本较大
v1版本（标准建造者模式）：
image
v2版本（静态内部类实现，更常用）：
image
单例模式*
- 定义：保证一个类仅有一个实例，并提供一个全局访问点
- 类型：创建型
- 适用场景：想确保任何情况下都绝对只有一个实例
- 优点：
- 在內存里只有一个实例，减少了内存开销
- 可以避免对资源的多重占用
- 设置全局访问点，严格控制访问
- 缺点：没有接口，扩展困难
- 重点：
- 私有构造器
- 线程安全
- 延迟加载
- 序列化和反序列化安全
- 反射（防止反射破坏单例）
原型模式
- 定义
- 指原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
- 不需要知道任何创建的细节，不调用构造函数
- 类型：创建型
- 适用场景
- 类初始化消耗较多资源
- new产生的一个对象需要非常繁琐的过程（数据准备、访问权限等）
- 构造函数比较复杂
- 循环体中生产大量对象时
- 优点
- 原型模式性能比直接new一个对象性能高
- 简化创建过程
- 缺点
- 必须配备克隆方法
- 对克隆复杂对象或对克隆出的对象进行复杂改造时，容易引入风险
- 深拷贝、浅拷贝要运用得当（要深克隆时，需要对象的引用对象也要实现克隆方法，并在对象的克隆方法调用引用对象的克隆方法）
外观模式*
- 定义：又叫门面模式，提供了一个统一的接口，用来访向子系统中的一群接口
- 外观模式定义了一个高层接口，让子系统更容易使用
- 类型：结构型
- 适用场景
- 子系统越来越复杂，增加外观模式提供简单调用接口
- 构建多层系统结构，利用外观对象作为每层的入口，简化层间调用
- 优点
- 简化了调用过程，无需了解深入子系统，防止带来风险。
- 减少系统依赖、松散耦合
- 更好的划分访问层次
- 符合迪米特法则，即最少知道原则
- 缺点
- 增加子系统、扩展子系统行为容易引入风险
- 不符合开闭原则
image
装饰者模式*
- 定义：在不改变原有对象的基础之上，将功能附加到对象上
- 提供了比继承更有弹性的替代方案（扩展原有对象功能）
- 类型：结构型
image
适配器模式*
定义：将一个类的接口转换成客户期望的另一个接口
使原本接口不兼容的类可以一起工作
类型：结构型
-
适用场景
- 已经存在的类，它的方法和需求不匹配时（方法结果相同或相似）
- 不是软件设计阶段考虑的设计模式，是随着软件维护，由于不同产品、不同厂家造成功能类似而接口不相同情况下的解决方案
-
优点
- 能提高类的透明性和复用，现有的类复用但不需要改变
- 目标类和适配器类解耦，提高程序扩展性
- 符合开闭原则
-
缺点
- 适配器编写过程需要全面考虑，可能会增加系统的复杂性
- 增加系统代码阅读难度
分类：对象适配器；类适配器
-
类适配器UML
image 对象适配器UML
image
享元模式*
- 定义：提供了减少对象数量从而改善应用所需的对象结构的方式
- 运用共享技术有效地支持大量细粒度的对象
- 类型：结构型
- 适用场景
- 常常应用于系统底层的开发，以便解决系统的性能问题
- 系统有大量相似对象、需要缓冲池的场景。
- 优点
- 减少对象的创建，降低内存中对象的数量，降低系统的内存，提高效率
- 减少内存之外的其他资源占用
- 缺点
- 需要关注内/外部状态、关注线程安全问题
- 使系统、程序的逻辑复杂化
image
组合模式
- 定义：将对象组合成树形结构以表示”部分-整体”的层次结构
- 组合模式使客户端对单个对象和组合对象保持一致的方式处理
- 类型：结构型
- 适用场景
- 希望客户端可以忽略组合对象与单个对象的差异时
- 处理一个树形结构时
- 优点
- 清楚地定义分层次的复杂对象，表示对象的全部或部分层次
- 让客户端忽略了层次的差异，方便对整个层次结枃进行控制
- 简化客户端代码
- 符合开闭原则
- 缺点
- 限制类型时会较为复杂
- 使设计变得更加抽象
image
桥接模式*
- 定义：将抽象部分与它的具体实现部分分离，使它们都可以独立地变化
- 通过组合的方式建立两个类之间联系，而不是继承
- 类型：结构型
- 适用场景
- 抽象和具体实现之间增加更多的灵活性
- 一个类存在两个（或多个）独立变化的维度，且这两个（或多个）维度都需要独立进行扩展
- 不希望使用继承，或因为多层继承导致系统类的个数剧增
- 优点
- 分离抽象部分及其具体实现部分
- 提高了系统的可扩展性
- 符合开闭原则
- 符合合成复用原则
- 缺点
- 增加了系统的理解与设计难度
- 需要正确地识别出系统中两个独立变化的维度
image
代理模式*
- 定义：为其他对象提供一种代理，以控制对这个对象的访问
- 代理对象在客户端和目标对象之间起到中介的作用
- 适用场景
- 保护目标对象
- 增强目标对象
- 优点
- 代理模式能将代理对象与真实被调用的目标对象分离
- 一定程度上降低了系统的耦合度，扩展性好
- 保护目标对象
- 缺点
- 代理模式会造成系统设计中类的数目增加
- 在客户端和目标对象增加一个代理对象，会造成请求处理速度变慢
- 增加系统的复杂度
- 代理的分类
- 静态代理
- 动态代理
- CGLib代理
- 扩展：Spring代理选择
- 当Bean有实现接口时， Springi就会用JDK的动态代理
- 当Bean没有实现接口时， Spring使用 CGlib
- 可以强制使用 CGlib
- 在 springi配置中加入<aop:aspectj-autoproxy proxy- target-class="true"/>
image
模板方法模式*
定义:定义了一个算法的骨架,并允许子类为一个或多个步骤提供实现
模板方法使得子类可以在不改变算法结构的情况下,重新定义算法的某些步骤
类型：行为型
-
适用场景
- 一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现
- 各子类中公共的行为被提取出来并集中到一个公共父类中,从而避免代码重复
-
优点
- 提高复用性
- 提高扩展性
- 符合开闭原则
-
缺点
- 类数目增加
- 增加了系统实现的复杂度
- 继承关系自身缺点,如果父类添加新的抽象方法,所有子类都要改一遍
image
迭代器模式
- 定义：提供一种方法，顺序访问一个集合对象中的各个元素，而又不暴露该对象的内部表示
- 类型：行为型
- 适用场景
- 访问一个集合对象的内容而无需暴露它的内部表示
- 为遍历不同的集合结构提供一个统一的接口
- 优点：分离了集合对象的遍历行为
- 缺点：类的个数成对增加
image
策略模式*
- 定义：定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化不会影响到使用算法的用户。
- 类型：行为型
- 适用场景
- 系统有很多类，而他们的区别仅仅在于他们的行为不同
- 一个系统需要动态地在集中算法中选择一种
- 优点
- 符合开闭原则
- 避免使用多重条件转移语句
- 提高算法的保密性和安全性
- 缺点
- 客户端必须知道所有的策略类，并自行决定使用哪一个策略类
- 产生很多策略类
image
观察者模式
- 定义：定义了对象之间的一对多依赖，让多个观察者对象同时监听某一个主题对象，当主题对象发生变化时，它的所有依赖者（观察者）都会收到通知并更新
- 适用场景：关联行为场景，建立一套触发机制
- 优点
- 观察者和被观察者之间建立一个抽象的耦合
- 观察者模式支持广播通信
- 缺点
- 观察者之间有过多的依赖细节，提高时间消耗及程序的复杂度
- 使用要得当，要避免循环调用
image
备忘录模式
- 定义：保存一个对象的某个状态，以便在适当的时候恢复对象
- 类型：行为型
- 适用场景
- 保存及恢复数据相关业务场景
- 随时可以恢复到之前的状态
- 优点
- 为用户提供一种可恢复机制
- 存档信息的封装
- 缺点：资源占用
image
命令模式
- 定义
- 将“请求”封装城对象，以便使用不同的请求
- 命令模式解决了应用程序中对象的职责以及他们之间的通讯方式
- 类型：行为型
- 适用场景
- 请求调用者和请求接收者需要解耦，使得调用者和接收者不直接交互
- 需要抽象出等待执行的行为
- 优点
- 降低耦合
- 容易扩展新命令或者一组命令
- 缺点：命令的无限扩展会增加类的数量，提高系统实现复杂度
image
中介者模式
- 定义
- 定义一个封装一组对象如何交互的对象
- 通过使对象明确地相互引用来促进松散耦合，并允许独立地改变他们的交互
- 类型：行为型
- 适用场景
- 系统中对象之间存在复杂的引用关系，产生的相互依赖关系结构混乱且难以理解
- 交互的公共行为，如果需要改变行为则可以增加新的中介者类
- 优点
- 将一对多转化为一对一、降低程序复杂度
- 类之间解耦
- 缺点：中介者过多，导致系统复杂
image
责任链模式*
- 定义：为请求创建一个接收此次请求对象的链
- 类型：行为型
- 适用场景：一个请求的处理需要多个对象当中的一个或多个协作处理
- 优点
- 请求的发送者和接收者（请求的处理）解耦
- 责任链可以动态组合
- 缺点
- 责任链太长或者处理时间过长，影响性能
- 责任链有可能过多
image
访问者模式
- 定义
- 封装作用于某数据结构（如List/Set/Map等）中的各元素的操作
- 可以在不改变各元素的类的前提下，定义作用于这些元素的操作
- 类型：行为型
- 适用场景
- 一个数据结构（如List/Set/Map等）包含很多类型对象
- 数据结构与数据操作分离
- 优点：增加新的操作很容易，即增加一个新的访问者
- 缺点
- 增加新的数据结构困难
- 具体元素变更比较麻烦
image
状态模式*
- 定义：运行一个兑现在其内部状态改变时，改变它的行为
- 类型：行为型
- 适用场景：一个对象存在多个状态（不同状态下行为不同），且状态可相互转换
- 优点：
- 将不同的状态隔离
- 把各种状态的转换逻辑分布到状态State的子类中，减少相互间依赖
- 增加新的状态非常简单
- 缺点：状态多的业务场景导致类数目增加，系统变复杂
image
