呆呆的猫的博客

需求: client 知道很多不同的策略, 希望在运行时切换.场景示例: 就像高德地图一样, 导航到某地, 用户可选择其一: 地铁, 自驾, 打车, 自行车 等.实现方式: 定义策略接口, 上层组合该接口. client 在运行时切换 具体策略.

如果是一套标准流程, 但有多种实现, 可以用 template 模板模式.例如, 如果要开发一个数据挖掘程序, 支持输入 word, csv, pdf. 他们其实是相同的流程(如打开文件, 读取数据, 转换数据, 输出数据).因为每种类别的流程相同, 所以每种类别的实现有很多重复代码.为了消除这些重复代码, 可以定义基类, 实现通用的逻辑, 如果有个性化的逻辑再覆盖.

作为中介者, 协调各对象

在 client 和 object 之间增加一个 command 层, 可以延迟执行 或 远程执行

保存状态快照，随时恢复指定版本

visitor 模式强调的是 "访问" 的动作如果 visitor 希望访问 interviewee, 可以让 interviewee 提供 accept() 方法, 该方法内部调用的还是 visitor.visit() 方法好处是: interviewee 可以方便扩展增加更多 visitor 的访问

为了集合数据的安全性, 或方便迭代, 可以用迭代器接口. 屏蔽复杂的内部逻辑, 外部只能使用迭代器遍历

在不同的情况下, 执行对应的操作. 通常是由 if else 实现的. 但随着需求扩张, 代码无法维护可以描述出各种状态(即各种 if 的条件), 把状态切换的控制流, 和状态的具体操作的业务流, 拆分开.通常 Context 类持有 state 接口, state 接口有很多实现每种 state 的实现, 都持有 Context 类的反向引用用于切换状态, 并只负责当前状态需执行的操作

如果需按顺序, 执行一系列步骤, 可用责任链.链条上的每个步骤, 都持有下一个步骤的引用, 当自身步骤执行完毕后, 执行下一个步骤.在运行时, client 也可以主动编辑 链的顺序.核心是, 各步骤都实现相同的接口.

发布订阅模式, client 都可以向 broker 注册, broker 管理所有 connection, 当 broker 收到某事件时, 广播给所有 clients.- 各种消息队列, 如 kafka, redis stream 都是这种结构 - websocket server, live video streaming server 也都是这样的

大量重复的对象, 如果很消耗资源, 没必要每次都初始化, 可以共用, 共享. 这就是 flyweight 享元模式.各种池技术: 线程池, 数据库连接池, http 网络连接池, 都是应用场景

树状结构, 适合用组合模式, 不断递归, 对各子节点求和, 直到叶子节点为止.例如, 一个大盒子, 内可以放置物体, 或若干小盒子. 而每个小盒子又同理.

如果有一个复杂的系统, 内部有很多子系统, 可以用 facade 封装一层, 只暴露出用户关心的简单接口.

通常用于老旧系统, 或第三方系统, 提供一层适配器或插件, 做协议转换PS: 如果开发新系统, 各层之间的解耦, 成为 bridge 桥接模式. 而如果是老系统则称为 adapter 适配器模式. 本质是一样的. 都是通过添加中间层实现的.

如果希望增强行为，可以使用 decorate 模式。且支持嵌套多层（套娃）

如下场景，1. 复杂逻辑拆分, 2. 多维，避免组合爆炸，可以使用

proxy 模式：如果 client 需要操作一个 rawObject, 但希望 proxy 它时, 则可使用 proxy 模式.

如果希望 复制对象, 可使用 "prototype 模式"如果 "待复制的对象" 是 interface 而不是 class, 或者如果 class 有 private 变量时. 无法知道 "待复制的对象"的细节, 则需要其实现 "clone()" 方法供外部调用.

将对象的构建, 拆分为若干步骤。每次创建对象时, 都通过 builder 对象执行其中的部分步骤

工厂设计模式分为：简单工厂、工厂方法、抽象工厂

单例分为, 执行时机分为: 饿汉, 懒汉两种

设计模式：策略模式

uml 类图的属性、方法，和关系图解

设计模式：工厂方法模式

本文介绍状态模式的背景、结构、使用场景