大名鼎鼎的GOF的设计模式是最著名的一本里程碑的作品
=模式分类=
=模式之间的关系=
=如何应用模式=
DP中的引言说得很好,如何应该模式来解决设计问题
* 寻找合适的对象
对象包括数据和操作, 对象在收到请求(或消息)后, 执行相应的操作
客户请求是使对象执行操作的唯一方法, 操作又是对象改变内部数据的唯一方法
(这就是封装的意义,之所以强调对象的成员应该是私有的原因)
OOD最困难的部分就是将系统分解成对象集合,因为要考虑许多因素:
封装,粒度,信赖关系,灵活性,性能,演化,复用等等,它们之间也互相有所影响或冲突.
设计模式可以帮助我们确定那些并不明显的抽象和描述这些抽象的对象,如Strategy, State,etc.
==决定对象的粒度==
如何决定对象的大小,数目以及范围呢, 设计模式亦有所帮助:
Facade 描述了怎样用对象表示完整的子系统
Flyweight
Abstact Factory
Builder
Visitor
Command
==指定对象接口==
对象接口描述了该对象所能接受的全部请求的集合, 也就是它能够提供哪些服务(方法)
当给对象发送请求时, 所引起的具体操作既与请求本身有关,又与接受对象有关
支持相同请求的不同对象可能对请求激发的操作有不同的实现(动态绑定和多态)
而设计模式通过确定接口的主要组成部分及经接口发送的数据类型, 来帮助你定义接口.
DP也许还会告诉你接口中不应包括哪些东西, 比如Memento模式所规定的接口
DP也指定了接口之间的关系,特别地,它常要求一些类具有相同或相似的接口,或对一些类的接口作出一些限制
如Decorator, Proxy模式要求修饰/代理对象和被修饰/受代理的对象接口保持一致
Visitor模式中Vistor接口必须反映能访问的对象的所有类
==描述对象的实现==
* 类继承还是接口继承呢
* 针对接口编程,而不是针对实现编程
==运用复用机制==
1.优先使用对象组合,而不是类继承
2.委托
3.继承和泛型的比较
==关联运行时刻和编译时刻的结构==
==设计应支持变化==
* 设计中常出现的问题
** 通过显式地指定一个类来创建对象
*** Factory , Prototype
** 对特殊操作的依赖
*** Chain of Reponsibility, Command
** 对硬件和软件平台的依赖
*** Abstract Factory, Bridge
** 对对象表示或实现的依赖
** 算法依赖
** 紧耦合
*** Abstract Factory, command, facade, mediator, observere,chain of responsibility
** 通过生成子类来扩充功能
*** Bridge, Chain of Reponsibility, composite, Decorator, Observer, Strategy
** 不能方便地对类进行修改
*** Adapter, Decorator, visitor
=如何选择设计模式=
* 考虑设计模式是如何解决设计问题的
* 浏览模式的意图部分
* 研究模式怎样互相关联
* 研究目的相似的模式
* 检查重新设计的原因
* 考虑你的设计中哪些是可变的
=怎样使用设计模式=
* 大致浏览一遍模式
* 回头研究结构部分
* 看代码示例部分
* 选择模式参考者的名字, 使它们在应用上下文中有意义
* 定义类
* 定义模式中专用于应用的操作名称
* 实现执行模式中责任和协作的操作