设计模式的源码地址

设计模式Github源码

工厂方法模式

1. 定义与类型

  • 定义:定义一个创建对象的接口,但让实现这个接口的类来决定实例化哪个类,工厂方法让类的实例化推迟到子类中进行
  • 类型:创建型

2. 适用场景

  • 创建对象需要大量重复的代码
  • 客户端(应用层)不依赖于产品类实例如何被创建,实现等细节
  • 一个类通过其子类来指定创建哪个对象

3. 优点

  • 用户只需要关心所需产品对应的工厂,无须关心创建细节
  • 加入新产品符合开闭原则,提高可扩展性

4. 缺点

  • 类的个数容易过多,增加复杂度
  • 增加了系统的抽象性和理解难度

抽象工厂

1. 定义与类型

  • 定义:抽象工厂模式提供创建一系列相关或相互依赖对象的接口
  • 无须指定他们具体的类
  • 类型:创建型

2. 适用场景

  • 客户端(应用层)不依赖于产品类实例如何被创建,实现等细节
  • 强调一系列相关的产品对象(属于同一产品族)一起使用创建对象需要大量重复的代码
  • 提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体实现

3. 优点

  • 具体产品在应用辰代码隔离,无须关心创建细节
  • 将一个系列的产品族统一到一起创建

4. 缺点

  • 规定了所有可能被创建的产品集合,产品族中扩展新的产品困难,需要修改抽象工厂的接口
  • 增加了系统的抽象性和理解难度

建造者模式

1. 定义与类型

  • 定义:将一个复杂对象的构建与它的表示分类,使得同样的构建过程可以创建不同的表示
  • 用户只需指定需要建造的类型就可以得到它们,建造过程及细节不需要知道
  • 类型:创建型

2. 适用场景

  • 如果一个对象有非常复杂的内部结构(很多属性)
  • 想把复杂对象的创建和使用分离

3. 优点

  • 封装性好,创建和使用分离
  • 扩展性好,建造类之间独立,一定程度上解耦

4. 缺点

  • 产生多余的Builder对象
  • 产品内部发生变化,建造者都要修改,成本较大

单例模式

1. 定义与类型

  • 定义:保证一个类仅有一个实例,并提供一个全局访问点
  • 类型:创建型

2. 适用场景

  • 想确保任何情况下都绝对只有一个实例

3. 优点

  • 在内存里只有一个实例,减少了内存开销
  • 可以避免对资源的多重占用
  • 设置全局访问点,严格控制访问

4. 缺点

  • 没有接口,扩展困难

5. 重点

  • 私有构造器
  • 线程安全
  • 延迟加载
  • 序列化和反序列化安全
  • 反射

原型模式

1. 定义与类型

  • 定义:指原型实例指定创建对象的种类,并且通过拷贝这些原型创建新对象
  • 不需要知道任何创建的细节,不调用构造函数\
  • 类型:创建型

2. 适用场景

  • 类初始化消耗较多资源
  • new产生的一个对象需要非常繁琐的过程(数据准备,访问权限等)
  • 构造函数比较复杂
  • 循环体中产生大量的对象

3. 优点

  • 原型模式性能比直接new一个对象性能高
  • 简化创建过程

4. 缺点

  • 必须配备克隆方法
  • 对克隆复杂对象或对克隆出的对象进行复杂改造时,容易引入风险

5. 扩展

  • 深克隆
  • 浅克隆

外观模式

1. 定义与类型

  • 定义:又叫门面模式,提供一个统一的接口,用来访问子系统中的一群接口
  • 外观模式定义了一个高层接口,让子系统更容易使用
  • 类型:结构型

2. 使用场景

  • 子系统越来越复杂,增加外观模式提供简单调用接口
  • 构建多层系统结构,利用外观对象作为每层的入口,简化层间调用

3. 优点

  • 简化了调用过程,无需了解深入子系统,防止带来风险
  • 减少系统依赖,松散耦合
  • 更好的划分层次
  • 符合迪米特法则,即最少知道原则

4. 缺点

  • 增加子系统,扩展子系统行为容易引入风险
  • 不符合开闭原则

装饰者模式

1. 定义与类型

  • 定义:在不改变原有对象的基础之上,将功能附加到对象上
  • 提供了不继承更有弹性的替代方案(扩展原有对象功能)
  • 类型:结构型

2. 适用场景

  • 扩展一个类的功能或给一个类添加附加职责
  • 动态的给一个对象添加功能,这些功能可以再动态的撤销

3. 优点

  • 继承的有力补充,比继承灵活,不改变原有对象的情况下给一个对象扩展功能
  • 通过使用不同装饰类以及这些装饰类的排列组合,可以实现不同效果
  • 符合开闭原则

4. 缺点

  • 会出现更多的代码,更多的类,增加程序复杂性
  • 动态装饰时,多层装饰时会更复杂

适配器模式

1. 定义与类型

  • 定义:将一个类的接口转换成客户期望的另一个接口
  • 使原本接口不兼容的类可以一起工作
  • 类型:结构型

2. 适用场景

  • 已经存在的类,它的方法和需求不匹配时(方法结构相同或类似)
  • 不是软件设计阶段考虑的设计模式,是随着软件维护,由于不同产品,不同厂家造成功能类似而接口不相同情况下的解决方案

3. 优点

  • 能提高类的透明性和复用,现有的类复用但不需要改变
  • 目标类和适配类解耦,提高程序扩展性
  • 符合开闭原则

4. 缺点

  • 适配器编写过程需要全民考虑,可能会增加系统的复杂性
  • 增加系统代码可读的难度

5. 扩展

  • 对象适配器
  • 类适配器

享元模式

1. 定义与类型

  • 定义:提供了减少对象数量从而改善应用所需的对象结构的方式
  • 运用共享技术有效地支持大量细粒度的对象
  • 类型:结构型

2. 适用场景

  • 常常用于系统底层的开发,以便解决系统的性能问题
  • 系统有大量相似对象,需要缓冲池的场景

3. 优点

  • 减少对象的创建,降低内存中对象的数量,降低系统的内存,提高效率
  • 减少内存之外的其他资源占有

4. 缺点

  • 关注内/外部状态,关注线程安全问题
  • 是系统,程序的逻辑复杂化

5. 扩展

  • 内部状态
  • 外部状态

组合模式

1. 定义与类型

  • 定义:将对象组合成树型结构以表示”部分-整体”的层次结构
  • 组合模式使客户端对单个对象和组合对象保持一致的方式处理
  • 类型:结构型

2. 适用场景

  • 希望客户端可以忽略组合对象和单个对象的差异时
  • 处理一个树形结构时

3. 优点

  • 清除地定义层次的复杂对象,表示对象的全部或部分层次
  • 让客户端忽略了层次的差异,方便对整个层次结构进行控制
  • 简化客户端代码
  • 符合开闭原则

4. 缺点

  • 限制类型时会较为复杂
  • 是设计变得更加抽象

桥接模式

1. 定义与类型

  • 定义:将抽象部分与它的具体实现部分分离,使它们都可以独立地变化
  • 通过组合的方式建立两个类之间联系,而不是继承
  • 类型:结构型

2. 适用场景

  • 抽象和具体实现之间增加更多的灵活性
  • 一个类存在两个(或多个)独立变化的维度,且这两个(或多个)
  • 不希望使用继承,或因为多层继承导致系统类的个数剧增

3. 优点

  • 分离抽象部分及具体实现部分
  • 提高了系统的可扩展性
  • 符合开闭原则
  • 符合合成复用原则

4. 缺点

  • 增加了系统的理解与设计难度
  • 需要正确地识别出系统中两个独立变化的维度

模板方法

1. 定义与类型

  • 定义:定义了一个算法的骨架,并允许子类为一个或多个步骤提供实现
  • 模板方法使子类可以在不改变算法结构的情况下,重新定义算法的某些步骤
  • 类型:行为型

2. 适用场景

  • 一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现
  • 各子类中公共的行为被提取出来并集中到一个公共父类中,从而避免代码重复

3. 优点

  • 提高复用性
  • 提高扩展性
  • 符合开闭原则

4. 缺点

  • 类数目增加
  • 增加了系统实现的复杂度
  • 继承关系自身缺点,如果父类添加新的抽象方法,所有子类都要改一遍

迭代器模式

1. 定义与类型

  • 定义:提供一种方法,顺序访问一个集合对象中的各个元素,而又不暴露该对象的内部表示
  • 类型:行为型

2. 适用场景

  • 访问一个集合对象的内容而无暴露它的内部表示
  • 为遍历不同的集合结构提供一个统一的接口

3. 优点

  • 分离了集合对象的遍历行为

4. 缺点

  • 类的个数成对增加

策略模式

1. 定义与类型

  • 定义:定义了算法家族,分别封装起来,让它们之间可以相互替换,此模式让算法的变化不会影响到使用算法的用户
  • 类型: 行为型

2. 适用场景

  • 系统有很多类,而他们的区别仅仅在于他们的行为不同
  • 一个系统需要动态地在几种算法中选择一种

3. 优点

  • 开闭原则
  • 避免使用多重条件转移语句
  • 提高算法的保密性和安全性

4. 缺点

  • 客户端必须知道所有的策略类,并自行决定使用哪个策略类
  • 产生很多策略类

解释器模式

1. 定义与类型

  • 定义:给定义一个语言,定义它的文法的一种表示,并定义一个解释器,这解释器使用该表示来解释语言中的句子
  • 为了解释一种语言,而为语言创建的解释器
  • 类型: 行为型

2. 适用场景

  • 某个特定类型问题发生频率足够高

2. 优点

  • 语法由很多类表示,容易改变及扩展此语言

3. 缺点

  • 当语法规则数目太多时,增加了系统复杂度

观察者模式

1. 定义与类型

  • 定义:定义了对象之间的一对多依赖,让多个观察者对象同时监听某一个主题对象,当主题对象发送变化时,它的所有依赖者(观察者)都会收到通知并更新
  • 类型:行为型

2. 适用场景

  • 关联行为场景,建立一套触发机制

3. 优点

  • 观察者和被观察者之间建立一个抽象的耦合
  • 观察者模式支持广播通信

4. 缺点

  • 观察者之间有过多的细节依赖,提高时间消化及程序复杂度
  • 使用要得当,要避免循环调用

备忘录模式

1. 定义与类型

  • 定义:保存一个对象的某个状态,以便在适当的时候恢复对象
  • 后悔药
  • 类型: 行为型

2. 适用场景

  • 保存及恢复数据相关业务场景
  • 后悔的时候,即想恢复到之前的状态

3. 优点

  • 为用户提供一种可恢复机制
  • 存档信息的封装

4. 缺点

  • 资源占有

命令模式

1. 定义与类型

  • 定义:将请求封装成对象,以便使用不同的请求
  • 命令模式解决了应用程序中对象的职责以及它们之间的通讯方式
  • 类型:行为型

2. 适用场景

  • 请求调用者和请求接收者需要解耦,使得调用者和接收者不直接交互
  • 需要抽象出等待执行的行为

3. 优点

  • 降低耦合
  • 容易扩展新命令或者一组命令

4. 缺点

  • 命令的无限扩展会增加类的数量 提高系统实现复杂度

中介者模式

1. 定义与类型

  • 定义一个封装一组对象如何交互的对象
  • 通过使对象明确地相互引用来促进松散耦合,并允许独立地改变它们的交互
  • 类型:行为型

2. 适用场景

  • 系统中对象之间存在复杂的音乐关系,产生的相互依赖关系结构混乱且难以理解
  • 交互的公共行为,如果需要改变行为则可以增加新的中介类

3. 优点

  • 将一对多转化成一对一,降低程序复杂度
  • 类之间解耦

4. 缺点

  • 中介者过多,导致系统复杂

责任链模式

1. 定义与类型

  • 为请求创建一个接收此次请求对象的链
  • 类型:行为型

2. 适用场景

  • 一个请求的处理需要多个对象当中的一个或几个协作处理

3. 优点

  • 请求的发送者和接收者(请求的处理)解耦
  • 责任链可以动态组合

4. 缺点

  • 责任链太长或者处理时间过长,影响性能
  • 责任链有可能过多

访问者模式

1. 定义与类型

  • 封装作用于某数据结构(如:list/set/map等)中的各元素的操作
  • 可以在不改变各元素的类的前提下,定义作用于这些元素的操作
  • 类型:行为型

2. 适用场景

  • 一个数据结构(如:list/set/map等)包含很多类型对象
  • 数据结构与数据操作分离

3. 优点

  • 增加新的操作很容易,即增加一个新的访问者

4. 缺点

  • 增加新的数据结构困难
  • 具体元素变更比较麻烦

状态模式

1. 定义与类型

  • 运行一个对象在其内部状态改变时,改变它的行为
  • 类型:行为型

2. 适用场景

  • 一个对象存在多个状态(不同状态下行为不同),且状态可相互转换

3. 优点

  • 将不同状态隔离
  • 把各种状态的转换逻辑,分布到State的子类中,减少相互间依赖
  • 增加新的状态非常简单

4. 缺点

  • 状态多的业务场景导致类数目增加,系统变复杂