Refresh design pattern
Posted mengdd
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Refresh design pattern相关的知识,希望对你有一定的参考价值。
多年后, 再次翻阅设计模式书籍, 将每种模式的要点总结于此, 需要本身有一定设计模式基础, 再结合要点, 帮助更好理解与运用.
- 策略模式 (Strategy)
- 附加功能单独抽象不同接口
- 功能以组合方式引入抽象类
- 抽象类封装功能模块各调用
- 实现类可在构造中配置功能具体实现
- 观察者模式 (Observer)
- 被订阅者持有所有订阅者
- 数据更新可以直接推送
- 数据更新也可以通知加拉取
- 大程度解耦观察者与被订阅者
- 装饰器模式 (Decorator)
- 装饰器接口的简单实现叫做组件
- 持有组件对象的叫做装饰器
- 装饰是从里层的装饰器开始
- 最里层的装饰器会持有原始组件
- 各层通过对持有的底层对象进行包装完成所谓装饰并返回给上层
- 理论上可以做到一层套一层无穷尽
- 工场方法模式 (Factory Method)
- 解耦产品的实现与使用
- 产品需要进行抽象
- 工场方法定义创建产品的接口
- 工场方法内还可以封装使用过程
- 子工场配置自己的创建逻辑
- 工场方法常常与抽象工场结合
- 抽象工场定义了一组产品的创建
- 工厂方法的实现又用这些产品创建或组件具体的大产品
- 工厂方法通过继承来实现
- 抽象工场通过组合来实现(传入)
- 单例模式 (Singleton)
- 全局实例注意内存
- 多线程需要特殊照顾
- 命令模式 (Command)
- 解耦发请求者与执行请求者
- 命令内部可以直接执行也可以代理给被封装在内的接收者
- 命令支持撤销
- 宏命令包含多个命令同时调用
- 适配器模式 (Adapter)
- 对象适配器以组合来实现
- 类适配器以多继承来实现
- 新旧系统共用可双向适配
- 外观模式 (Facade)
- 从抽象层次看与适配器很像
- 外观模式创建新的简单接口
- 适配器模式使用已存在接口
- 新接口包装多个系统模块简化调用
- 老接口包装其他系统达到兼容
- 模板方法模式 (Template Method)
- 模板实现算法, 子类实现步骤
- 子类与父类尽量不能成环
- 好莱坞模式为子类全为回调方法
- 有默认实现的为钩子方法
- 策略用组合封装算法,模板用继承封装算法
- 工厂方法是特殊的模板方法
- 迭代器模式 (Iterator)
- 解耦游走数组而不要关心具体类型
- 集合类都有自己的迭代器
- 一般的迭代器具备hasNext与next两个方法
- 聚合器持有数据并创建迭代器
- 组合模式 (Composite)
- 组合模式的节点分为子节点与叶节点
- 子与叶都实现了同样的组合接口,所谓透明性
- 子节点会额外实现add与get
- 为了叶节点安全也可以具有不同接口
- 组合模式可以与迭代器共生
- 迭代器需要配合栈来实现树的遍历
- 子节点可以实现空迭代器来减少Null判断
- 状态模式 (State)
- 与策略模式类图相似
- 状态接口定义状态切换行为
- 所有状态实现统一接口
- 状态机定义并持有所有状态
- 状态机储存当前状态
- 状态切换由不同状态自己控制
- 状态内通过持有的状态机来切换下一状态
- 代理模式 (Proxy)
- 可分为远程代理与虚拟代理
- 与装饰者很像
- 代理更多的是控制真实对象的访问, 解耦客户与真实对象, 也可能帮助创建真实对象
- 装饰器更多是增加行为, 而且不创建对象
- 可通过工厂方法返回主体的代理
- 与适配器很像
- 代理不改变接口, 适配器改变接口
- 保护代理可以限制访问部分接口,更像适配器
- 复合模式 (Compound)
- 多用几种
- 比如MVC就融合了策略,组合,适配器等
一些冷门模式
- 桥接模式 (Bridge)
- 与策略模式很像
- 主体都依赖于功能组件的抽象
- 策略模式的主体是具体算法的实现
- 桥接模式的主更抽象,需要子类来实现不同算法
- 可以做到主体和功能组件解耦
- 增加了复杂度
- 生成器 (Builder)
- 封装复杂对象的创建过程
- 隐藏内部实现
- 创建时需要对所创对象有更多认识
- 责任链 (Resposibility)
- 简单理解为一个Handler的对象链
- 比如很多程序里常用的Dispatcher链
- 或者很多系统启动时需要加载的数据链
- 不能保证一定会有对象对数据进行处理
- 享元 (Flyweight)
- 多个同样的实例可被一个方法控制, 就可以封装在一起轮询数组进行处理
- 但是不能有独立不同行为了
- 解释器 (Interpreter)
- 主要是做简单固定语法解析
- 抽象解释接口, 并实现多个解释器
- 如And, Or之类的, 可相互嵌套.
- 如果语法复杂, 种类繁多, 会不太适合
- 中介者 (Mediator)
- 解耦不同对象
- 它们只需要通知中介者, 中介者根据不同状态来控制整个逻辑
- 可能会让中介者逻辑过于复杂
- 备忘录 (Momento)
- 将对象的储存抽出来, 更好的维护了业务的内聚
- 一般会提供储存与获取接口
- 储存过程可能会耗时
- 可能需要考虑序列化
- 原型 (Prototype)
- 提供复制对象的方法
- 比如clone
- 如果对象层次深,复制起来可能复杂
- 访问者 (Visitor)
- 解耦对象与每个对象的具体操作, 如对电脑的不同部件进行不同操作
- 在对象种类变化小而操作变化大的时候使用
- 每一个对象实现visitor接口, 接受(accept)一个visitor,并把自己传给visitor (visit)
- 缺点是具体元素对访问者暴露, 而不是抽象接口
有很多种分类方式, 不必拘泥, 也可忽略.
- 分类方式 I
- 创建型
- 单例
- 抽象工厂
- 工厂方法
- 生成器
- 原型
- 行为型
- 模板方法
- 迭代器
- 状态
- 策略
- 观察者
- 命令
- 解释器
- 中介者
- 访问者
- 备忘录
- 责任链
- 结构型
- 装饰器
- 代理
- 外观
- 组合
- 适配器
- 桥接
- 享元
- 创建型
- 分类方式 II
- 类
- 模板方法
- 工厂方法
- 适配器
- 解释器
- 对象
- 单例
- 抽象工厂
- 装饰器
- 代理
- 外观
- 组合
- 适配器
- 迭代器
- 状态
- 策略
- 观察者
- 命令
- 桥接
- 享元
- 生成器
- 中介者
- 访问者
- 备忘录
- 责任链
- 原型
- 类
以上是关于Refresh design pattern的主要内容,如果未能解决你的问题,请参考以下文章
refresh是什么?Spring refresh的12个步骤
Springboot actuator refresh 和 bus-refresh 总是返回 401 Unauthorized
AbstractApplicationContext(Spring)下refresh()方法的用途是啥?为啥使用 refresh() 后 bean 单例范围丢失?