一、各个模式总结
1、创建型模式
1)单例模式
Singleton Pattern
- 创建某个类的实例,该类的实例在系统中只有这一份
- 实现方式
- 八种方式:推荐用 枚举、内部静态类、DCL双重检测锁
- 案例
- java.lang.Runtime 就是经典的 单例模式(饿汉式)
2)简单工厂模式
Simple Factory Pattern
- 由工厂创建出产品类;客户端不用创建产品,直接从工厂获取;实现客户端和产品创建的解耦;如果客户端有多个,产品的创建过程一旦发生变化,只需在工厂里改变即可,客户端不用变,非常方便
3)抽象工厂模式
Abstract Factory Pattern
- 将工厂抽象成两层,AbsFactory(抽象工厂) 和具体实现的工厂子类。可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇,更利于代码的维护和扩展
4)原型模式
Prototype Pattern
- 用原型实例指定创建对象的种类,并且通过拷贝这些原型,创建新的对象;该类的对象在系统中存在多份
- 实现方式
- 浅拷贝 (默认)
- 基本数据类型:值传递
- 引用数据类型:引用传递
- 在一个对象中修改引用成员变量会影响到另一个对象的该成员变量值
- 深拷贝
- 对整个对象(包括对象的引用类型)进行拷贝
- 方式一:重写 clone() 方法
- 方式二:对象序列化 和 反序列化
- 浅拷贝 (默认)
5)建造者模式
Builder Pattern
-
一步一步创建一个复杂的对象,允许用户只通过指定复杂对象的类型和内容就可以构建它们,用户不需要知道内部的具体构建细节
-
四个角色
- 产品角色(Product):具体的产品对象
- 抽象建造者(Builder):创建 Product 对象的各个部件指定的接口/抽象类
- 具体建造者(ConcreteBuilder):实现接口,构建和装配各个部件
- 指挥者/经理(Director):构建使用 Builder 接口的对象。主要是用于创建复杂的对象
-
案例
- 需要建房子:过程为打桩、砌墙、封顶
- 房子有各种各样的,比如普通房,高楼,别墅,各种房子的建造过程虽然一样,但是细节不同
2、结构型模式
1)适配器模式
Adapter Pattern
-
将某个类的接口转换成客户端期望的另一个接口表示,主要目的是兼容性,让原本因接口不匹配,不能一起工作的两个类可以协同工作
-
客户端可以通过适配器,有选择地使用目标接口的方法(不是全部方法)(接口适配器)
-
分类
-
类适配器
适配器继承了目标对象类
-
-
对象适配器
适配器中聚合了目标对象
-
接口适配器
目标对象是接口,适配器(定义为抽象类),实现该接口,为该接口中每个方法提供一个默认实现(空方法),那么客户端作为该抽象类(适配器)的子类可有选择地覆盖父类的某些方法来实现需求
WindowAdapter 为窗口适配器类,里面有很多方法(窗口关闭、最小化、最大化……),我们只需要监听窗口关闭事件,所以 匿名内部类 只用实现 windowClosing() 方法即可
2)桥接模式
Bridge Pattern
-
把 抽象(Abstraction) 与 行为实现(Implementation) 分离开,从而可以保持各部分的独立性以及功能扩展
-
案例
对 不同品牌(华为、小米…) 不同类型(直立式、折叠式…) 的手机实现同样的功能(比如:开机、关机、上网,打电话等);当扩展品牌、类型时,非常方便
把款式和品牌分离开。品牌以聚合的形式加入手机中
3)装饰者模式
Decorator Pattern
-
动态的将新功能附加到对象上。在对象功能扩展方面,它比继承更有弹性
-
装饰者模式就像打包一个快递,一层一层地给物品添加外层包装
-
被装饰者
主体(Component):比如:陶瓷、衣服……
-
装饰者
包装(Decorator) :比如:报纸填充、塑料泡沫、纸板、木板……
-
- 案例:星巴克咖啡订单项目
- JDK IO 中的应用
Java的 IO 结构,FilterInputStream 就是一个装饰者
4)组合模式
Composite Pattern
-
依据树形结构来组合对象,用来表示部分以及整体层次
-
使得用户对单个对象和组合对象的访问具有一致性
-
案例
在一个页面中展示出学校的院系组成,一个学校有多个学院,一个学院有多个系
5)外观模式
Facade Pattern
-
通过定义一个一致的接口,用以屏蔽内部子系统的细节,使得调用端只需关心这个接口的调用,而无需关心子系统的内部细节
-
解决多个复杂接口带来的使用困难,起到简化用户操作的作用
-
案例
6)享元模式
Flyweight Pattern
-
池化技术
-
运用共享技术,有效地支持大量细粒度的对象
-
解决重复对象的内存浪费的问题
-
经典的应用场景是需要缓冲池的场景;比如:String 常量池、数据库连接池 、线程池
7)代理模式
Proxy Pattern
-
封装目标对象,并添加额外的功能,对客户端提供更多更优的服务
-
静态代理
-
动态代理
3、行为型模式
1)模版方法模式
Template Method Pattern
-
定义了操作中的算法的骨架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构,就可以重定义该算法的某些特定步骤
-
一般模板方法都加上 final 关键字,防止子类重写模板方法
-
案例
制作豆浆
流程:选材--->添加配料--->浸泡--->放到豆浆机打碎
通过添加不同的配料,可以制作出不同口味的豆浆;选材、浸泡和放到豆浆机打碎这几个步骤对于制作每种口味的豆浆都是一样的(红豆、花生豆浆。。。)
- 钩子方法
-
在模板方法模式的父类中,定义一个方法,默认不做任何事,子类可以视情况要不要覆盖它,该方法称为钩子
-
豆浆案例升级
- 制作原味纯豆浆,不添加任何的配料
-
2)命令模式
Command Pattern
- 消除了 请求发送者 与 请求接收者 之间的耦合,让对象之间的调用关系更加灵活,实现解耦
- 在命令模式中,会将一个请求封装为一个对象,以便使用不同参数来表示不同的请求(即命名),同时命令模式
也支持可撤销的操作
-
将发起请求的对象与执行请求的对象解耦。发起请求的对象是调用者,调用者只要调用命令对象的 execute()方法就可以让接收者工作,而不必知道具体的接收者对象是谁、是如何实现的,命令对象会负责让接收者执行请求的动作,也就是说:”请求发起者”和“请求执行者”之间的解耦是通过命令对象实现的,命令对象起到了纽带桥梁的作用
-
空命令也是一种设计模式,省去了判空的操作
-
案例
实现一个 app 控制所有智能家电的需要,则每个智能家电厂家都要提供一个统一的接口给 app 调用
3)访问者模式
Visitor Pattern
-
封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话,接受这个操作的数据结构则可以保持不变
-
适用于数据结构相对稳定的系统,它把 数据结构 和 作用于结构上的操作 之间的耦合解脱开,使得操作集合可以相对自由地演化
-
案例
购物车
添加不同类型商品的购物车,当点击结算的时候,它计算出所有不同商品需付的费用
通过访问者模式把计算逻辑转移到了另外一个类(访问者)上面商品接收访问者 accept(Visitor visitor),通过 visitor.visit(this) ,把商品本身传给访问者,访问者接收传递过来的商品,然后可以对该商品进行费用计算的逻辑,这样计算的逻辑就与商品本身解耦了。当计算逻辑发生变化后,不影响商品
组装电脑
电脑组成:可打折组件、不可打折组件
不同的人群有不同的折扣
由特定人群的客户,获取对应的价格
4)迭代器模式
Iterator Pattern
- 提供一种遍历集合元素的统一接口,用一致的方法遍历集合元素,不需要知道集合对象的底层表
示,即:不暴露其内部的结构
-
把 管理对象集合 和 遍历对象集合 的责任分开
-
案例
展示一个学校院系结构:在一个页面中展示出学校的院系组成,一个学校有多个学院, 一个学院有多个系
外部类:
迭代器以外部类的形式存在
内部类:
更加简洁
具体迭代器类 以内部类的形式组合在 具体学院类 中
5)观察者模式
Observer Pattern
-
对象之间多对一依赖的一种设计方案,被依赖的对象为 Subject,依赖的对象为 Observer,Subject 通知 Observer 变化
-
案例
气象站每天测量温度,湿度,气压等等
第三方能实时获取到最新的气象数据
6)中介者模式
Mediator Pattern
-
用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用,从而使其解耦,而且可以独立地改变它们之间的交互
-
MVC模式,C(Controller控制器)是 M(Model模型)和 V(View视图)的中介者,在前后端交互时起到了中间人的作用
-
案例
智能家庭项目
- 智能家庭包括各种设备,闹钟、咖啡机、电视机、窗帘等
- 主人要看电视时,各个设备可以协同工作,自动完成看电视的准备工作,比如流程为:
- 闹铃响起
- 咖啡机开始做咖啡
- 窗帘自动落下
- 电视机开始播放
同事之间(闹钟、咖啡机、电视、窗帘、电话)实现解耦,方便扩展
每个同事都与中介关联,图中只展示 闹钟和中介的关联,其余省略
7)备忘录模式
Memento Pattern
-
在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态
-
给用户提供了一种可以恢复状态的机制,可以使用户能够比较方便地回到某个历史的状态
-
案例
游戏角色有攻击力和防御力,在大战 Boss前保存自身的状态(攻击力和防御力),当大战 Boss后攻击力和防御力下降,从备忘录对象恢复到大战前的状态 可以存储多个角色的状态,每个角色有多个状态
8)解释器模式
Interpreter Pattern
- 在编译原理中,一个算术表达式通过词法分析器形成词法单元,而后这些词法单元再通过语法分析器构建语法分析树,最终形成一颗抽象的语法分析树。这里的词法分析器和语法分析器都可以看做是解释器
- 解释器模式(Interpreter Pattern):是指给定一个语言(表达式),定义它的文法的一种表示,并定义一个解释器,使用该解释器来解释语言中的句子(表达式)
- 应用场景
- 编译器
- 运算表达式计算
- 正则表达式
- 机器人等
9)状态模式
State Pattern
-
主要用来解决对象在多种状态转换时,需要对外输出不同的行为的问题。状态和行为是一一对应的,状态之间可以相互转换
-
案例
APP抽奖活动
具体要求如下:
- 假如每参加一次这个活动要扣除用户 50 积分,中奖概率是 10%
- 奖品数量固定,抽完就不能抽奖
- 活动有四个状态:可以抽奖、待抽奖、发放奖品和奖品领完
- 状态转换关系图
10)策略模式
Strategy Pattern
-
定义算法族(策略组),分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户
-
案例
鸭子项目,具体要求如下:
有各种鸭子(比如野鸭、北京鸭、玩具鸭等,鸭子有各种行为,比如叫、飞行等)
显示鸭子的信息
11)职责链模式
Chain of Responsibility Pattern
-
为请求创建了一个接收者对象的链。这种模式对请求的 发送者 和 接收者 进行解耦
-
职责链模式通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求,那么它会把相同的 请求传给下一个接收者,依此类推
-
最后一个接收者中包含的另一个接收者,应该是第一个接收者,形成环路
-
案例
学校 OA 系统的采购审批项目:
需求采购员采购教学器材
- 如果金额小于等于 5000,由教学主任审批
- 如果金额小于等于 10000,由院长审批
- 如果金额小于等于 30000,由副校长审批
- 如果金额超过 30000,有校长审批
二、部分模式的区别
1、适配器、外观、代理、命令、中介者 的区别
- 共同点
在操作方与被操作方之间,都存在一个中间层 - 主要目的区分
模式 | 主要目的 |
---|---|
适配器 Adapter | 让 客户端 与 目标对象 兼容,或者让客户有选择地使用目标中的某些方法 |
外观 Facade | 屏蔽 内部子系统(目标对象) 的细节,给客户端提供一个 统一的接口 |
命令 Command | 消除了命令 发送者 与 接收者 之间的耦合,实现调用关系的解耦;命令即对象 |
代理 Proxy | 封装目标对象,增加额外功能,提供更多更优服务;不关注对象间的交互 |
中介者 Mediator | 封装对象的交互,使对象不需要显式地相互引用,使其解耦 |
- 图解