申明:文章内容整理自《设计模式:可复用面向对象软件的基础》、第二幅插图来自极客时间《设计模式之美》。
如有谬误,还望指正!
设计模式的编目与分类
1. 设计模式的编目
共包含23个设计模式。它们的名字和意图列举如下,以使读者有个基本了解。
- Abstract Factory: 提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。
- Adapter: 将一个类的接口转换成客户希望的另外一个接口。 Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
- Bridge:将抽象部分与它的实现部分分离,使它们都可以独立地变化。
- Builder:将一个复杂对象的构建与它的示分离,使得同样的构建过程可以创建不同的表示。
- Chain of Responsibility:解除请求的发送者和接收者之间的耦合,使多个对象都有机会处理这个请求。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它。
- Command:将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可取消的操作
- Composite:将对象组合成树形结构以表示“分-整体”的层次结构. Composite使得客户对单个对象和组合对象的使用具有一致性。
- Decorator:动态地给一个对象添加一些额外职责。就扩展功能而言, Decorator模式比生成子类方式更为灵活。
- Facade:为子系统中的一组接口提供一个一致的界面, Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
- Factory Method:定义一个用于创建对象的接口,让子类决定将哪一个类实例化。 Factory Method使一个类的实例化延迟到其子类。
- Flyweight:运用共享技术有效地支持大量细粒度的对象。
- Interpreter:给定一个语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子。
- Iterator:提供一种方法顺序访问一个聚合对象中的各个元素,而又不需要暴露该对象的内部表示。
- Mediator:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
- Memento:在不破坏封装性的前提下,捕获个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
- Observer:定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
- Prototype:用原型实例指定创建对象的种类,并且通过拷贝这个原型来创建新的对象。roy4.7):为其他对象提供一个代理以控制对这个对象的访问。
- Singleton:保证一个类仅有一个实例,并提供一个访问它的全局访问点。
- State:允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
- Strategy:定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换本模式使得算法的变化可独立于使用它的客户。
- Template Method:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中.Template Method使得子类不改变一个算法的结构即可定义该算法的某些特定步骤。
- Visitor:表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各素的类的前提下定义作用于这些元素的新操作。
2. 设计模式的分类
怎样选择设计模式
在GOF一书中,有20多个设计模式可供选择,要从中找出一个针对特定设计问题的模式可能还是很困难的,尤其是当面对一组新模式,你还不怎么熟悉它的时候。
这里给出几个不同的方法,以帮助你发现适合你手头问题的设计模式:
- 考虑设计模式是怎样解决设计问题的
设计模式怎样帮助你找到合适的对象、决定对象的粒度、指定对象接口以及设计模式解决设计问题的几个其他方法。会有助于你找到合适的模式。 - 明确需要解决的问题
首先必须要明确知道自己的软件中存在什么样的问题。如果问题不够明确,是无法选择出合适的设计模式的。
比如,如果当前面临的问题非常明确,就是"对象太多,太浪费内存",那么我们就会知道"也许Flyweight"比较合适。因为Flyweight模式是通过共享对象来减少内存使用量的模式。 在学习设计模式时,我们要注意设计模式“可以解决什么问题” - 浏览模式的意图部分
在GOF书-1.4节列出了目录中所模式的意图( Intent)部分。通读每个模式的意图,找出和你的问题相关的一个或多个模式。你可以下表所显示的分类方法缩小你的搜查范围。
创建型 | 结构型 | 行为型 | |
---|---|---|---|
类 | Factory Method | Adapter(类) | Interpreter Template Method |
对象 | Abstract Factory Builder Prototype Singleton | Adaptor(对象) Bridge Composite Decorator Facade Flyweight Proxy | Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor |
怎样使用设计模式
一旦选择了一个设计模式,该怎么使用它呢? 这里给出一个有效应用设计模式的循序渐进的方法。
- 大致浏览一遍模式
特别注意其适用性部分和效果部分,确定它适合你的问题。 - 回头研究结构部分、参与者部分和协作部分
确保你理解这个模式的类和对象以及它们是怎样关联的。 - 看代码示例部分,看看这个模式代码形式的具体例子
研究代码将有助于你实现模式。 - 选择模式参与者的名字,使它们在应用上下文中有意义
设计模式参与者的名字通常过于抽象而不会直接出现在应用中。然而,将参与者的名字和应用中出现的名字合并起来是很有用的。这会帮助你在实现中更显式地体现出模式来。例如,如果你在文本组合算法中使用了Strategy模式, 那么你可能有名为Simple Layout Strategy或TeX Layout Strategy这样的类。 - 定义类
声明它们的接口,建立它们的继承关系,定义代表数据和对象引用的实例变量。识别模式会影响到你的应用中存在的类,并做出相应的修改。 - 定义模式中专用于应用的操作名称
这里再一次体现出名字一般依赖于应用。使用与每一个操作相关联的责任和协作作为指导。还有,你的名字约定要一致。例如,可以使用“Create-”前缀统一标记Factory方法。 - 实现执行模式中责任和协作
的操作实现部分提供线索指导你进行实现。代码示例部分的例子也能提供帮助。
这些只对你一开始使用模式起指导作用,以后你会有自己的设计模式使用方法。
关于设计模式,如果不提一下它们的使用限制,那么关于怎样使用它们的讨论就是不完整的。设计模式不能够随意使用。 通常你通过引入额外的间接层次获得灵活性和可变性的同时,也使设计变得更复杂和/或牺牲了一定的性能。一个设计模式只有当它提供的灵活性是真正需要的时候,才有必要使用。 当衡量一个模式的得失时,它的效果部分是最能提供帮助的。