> 对经典的23种设计模式介绍,来判断适合哪种设计模式进行设计
23种设计模式:
第1 部分 适应设计模式 |
|
Iterator 模式 |
迭代器,松耦合 |
Adapter 模式 |
适配器模式,使用同样的类,提高复用性,提供不同的API,像电压220到5V需要充电器(适配器) |
第2 部分 交给子类 |
|
Template Method 模式——将具体处理交给子类 |
template method 一个抽象类,写主要流程,具体方法的实现交由其子类 |
Factory Method 模式——将实例的生成交给子类 |
自己不new,所有的实例化操作由子类进行 |
第3 部分 生成实例 |
|
Singleton 模式——只有一个实例 |
单例模式,一个类只有一个实例,无论如何new |
Prototype 模式——通过复制生成实例 |
一系列的操作,重新new一个实例没有具体的操作值,使用复制生成我们想要的实例(clone) |
Builder 模式——组装复杂的实例 |
建筑模式,使用相同的数据构建不同的文档类型,如纯文本、html、jwt界面显示 |
Abstract Factory 模式——将关联零件组装成产品 |
将抽象零件组合成为抽象产品的抽象工厂 |
第4 部分 分开考虑 |
|
Bridge 模式——将类的功能层次结构与实现层次结构分离 |
利用委托(引用)的形式连接功能层次和实现层次,两边可同时拓展也可异步拓展 |
Strategy (策略)模式——整体地替换算法 |
策略模式,方便的替换算法,其它不变 |
第5 部分 一致性 |
|
Composite(混合物) 模式——容器与内容的一致性 |
使容器与内容具有一致性,并且可以创建出递归结构的Composite模式,如文件扫描中,文件夹和文件相同的容器实现递归扫描 |
Decorator(装饰) 模式——装饰边框与被装饰物的一致性 |
为对象添加装饰的设计模式被称为Decorator模式,更多的是对功能的扩展,例如在一个为一个字符串周围增加*号包裹 |
第6 部分 访问数据结构 |
|
Visitor 模式——访问数据结构并处理数据 |
用于对保存在数据结构中的元素进行某种特定的处理 |
Chain of Responsibility 模式——推卸责任 |
将多个对象组成一条职责链,然后按照他们在职责链上的顺序一个一个地找出这个任务应该谁来负责 |
第7 部分 简单化 |
|
Facade(窗口)模式——简单窗口(系统门面) |
多个类之间错综复杂的关系,做一个窗口(方法)直接调用即可完成(单向调用)功能。其实就是进行高级封装,直接调用实现功能 |
Mediator (仲裁者)模式——只有一个仲裁者 |
组员向仲裁者报告,仲裁者向组员下达指示。将处理逻辑都在同一个(双向调用)目的:仲裁地方处理,同一个地方进行操作 |
第8 部分 管理状态 |
|
Observer 模式——发送状态变化通知 |
被观察的对象发生变化时,会通知给观察者。目的:同步 |
Memento (备忘录)模式——保存对象状态 |
可以保存实例的状态,可以保存和恢复实例如:返回上一个状态(撤销)、历史记录、快照等 |
State 模式——用类表示状态 |
类表示状态,通过切换不同的类(状态),达到不同状态下执行不同的操作 |
第9 部分 避免浪费 |
|
Flyweight (享元)模式——共享对象,避免浪费 |
需要某个实例,并不总是通过new关键字生成实例,而是尽量共用已经存在的实例 目的:共享实例减少内存使用量缺点:改变被共享的实例,会对所有使用该实例的地方都产生影响 |
Proxy(代理) 模式——中间商 |
被调用方并不是真正的执行者,而是交由另一方代理执行 |
第10 部分 用类来表现 |
|
Command 模式——命令也是类 |
通过对象表示“命令”来保存命令历史记录和重复执行的命令 如:画画的每一个点都是一个命令类,当做一个命令来记录下来,可以重复执行一系列动作 |
Interpreter(解释器) 模式——语法规则也是类 |
解释器,其实就是通过自定义的某种语法来编程,如正则,最终都是转换成代码 如:java语法,底层也是需要一个解释器解释成汇编机器语言 |
参考:
《图解设计模式》
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/17892.html