本文的内容按照Gang of Four的《Design Patterns: Elements of Reusable Object-Oriented Software》，也就是通常所说的设计模式。
设计模式原本是建筑上的说法，指可重用的对问题的解决方案。
这里把这个概念借用到OO上，总结了Class的若然模式。不同模式有各自可以应用的问题，以及如何运用一定的语言特性来实现它的方法。
首先来说语言特性。《DP》一书是针对C++和SmallTalk来写，不同类型（动态/静态）的语言，和已经通过语言层面实现的特性，会影响到具体场合中会遇到的问题，以及解决方式。
下面行文的侧重会在类的常见使用方法上，会针对Class这个语言特性来说，并扩展到OO的层面上来。虽然只是记录下来书中在这些用法方面的展示出的冰山一角，但是我想这对于OO的运用以及设计的重用的方式方法都能引出广阔的视野的。
《DP》已经展示了语言相关的问题功能和使用的思路，它们涉及：的类型与接口，类与对象的用法，实现继承与接口继承，面向接口的编程与复用，使用对象的组合，对象的委托关系，对象间的聚合与相识，依赖耦合与灵活性，应用工具箱以及框架。
对此具体的一一解释仍见原书。下面来设法就其中的启示扯开一下：
对象本身是若干数据和方法的集合，它储存自身一份数据（对象说某接口的指针）并判断其所属的提供方法的类。对象可以被使用，调用对象的成员函数或向对象发送消息，可以使用对象提供的功能或者进行于对象状态相关的操作。对象可以被传递，可以传入一组数据或者功能，同时针对引用的传递可以是基于接口的或者表示使用的许可。对象间可以建立起层次和关联，这可以用来表现对象间的关系，和实现功能的重用。
不同的设计模式本身涉及了各自产生的问题环境，设计的意图，一定特性下的实现方法，封装产生的可变性与灵活性，以及模式间的关联。
同时设计模式是经验的总结，并不代表运用方法的方法全貌。而固定模式名称可以为设计与实现带来方便。
以下是《DP》中例举的模式，会列出原书的部分目录在略加注解：
第3章 创建型模式
创建一个符合界面的对象，返回指针
3.1 Abstract Factory（抽象工厂）
提供创建一组对象的工厂对象一直的界面
3.2 Builder（生成器）
将一步步创建对象操作交给一个对象
3.3 Factory Method（工厂方法）
把创建对象的操作放到具体类的成员方法中
3.4 Prototype（原型）
以克隆类对象的方式创建新对象
3.5 Singleton（单件）
实现只同时创建一个实例的类
3.6 创建型模式的讨论
关注的是创建对象的方法上
第4章 结构型模式
这里是讨论对象间的组合关系
4.1 Adapter（适配器）
为对象包装出所需的接口
4.2 Bridge（桥接）
连接分离的接口与实现部分
4.3 Composite（组成）
为枝和叶提供一致的界面
4.4 Decorator（装饰）
通过链式结构为对象的曾加功能
4.5 FACADE（外观）
为一组对象定义使用的界面
4.6 Flyweight（享元）
实现大量小对象的储存与操作
4.7 Proxy（代理）
控制或操作对另一对象的访问
4.8 结构型模式的讨论
4.8.1 Adapter与Bridge
4.8.2 Composite、Decorator与Proxy
是涉及接口的调整以及接口上的功能的讨论
第5章 行为模式
这里是讨论对象功能上的分配与执行
5.1 CHAIN OF RESPONSIBILITY（职责链）
以消息链的形式传递待处理的调用
5.2 Command（命令）
将操作实现为一个对象，方便储存传递
5.3 INTERPRETER（解释器）
用对象表示语法树的节点，并实现执行方法
5.4 ITERATOR（迭代器）
提供遍历某对象的功能界面
5.5 Mediator（中介者）
用一个对象负责一组对象间的消息传递
5.6 MEMENTO（备忘录）
用一个对象保存另一个对象的状态
5.7 OBSERVER（观察者）
一个对象改变时会通知它的观察者
5.8 STATE（状态）
用接口相同的子类表示不同状态
5.9 STRATEGY（策略）
封装算法到一个对象
5.10 TEMPLATE METHOD（模板方法）
用override来实现对象功能
5.11 VISITOR（访问者）
将能对某对象的操作的对象传递给被操作者使用
5.12 行为模式的讨论
5.12 1 封装变化
5.12.2 对象作为参数
5.12.3 通信应该被封装还是被分布
5.12.4 对发送者和接收者解耦
5.12.5 总结
这里关注的是对象的可替换与对象间通信
上述模式对OO的设计，也是若然对Class的使用方法。
关注的是通过封装使组件具有灵活性，而实现软件的规模与复用。
自己是按照笔记的态度来写的，内容在于整理和记录，并想把关注引到Class的用法上来。
传送：
《Design Patterns: Elements of Reusable Object-Oriented Software》
http://book.51cto.com/art/200706/50164.htm
http://en.wikipedia.org/wiki/Design_pattern
----
来补充下，其实是因为上面的内容有遗漏，不过结构有点乱了，只是来补完而已。
一个模式除了它的名称外，还包括其产生自的问题，应对的解决方案，使用后得到的效果。
语言的特性会影响解决某问题需要的代价，甚至不必额外的针对某种模式去实现。
一个对模式综合运用上Smalltalk的MVC（Model/View/Controller）。M会通知V数据的改变，一个M可以对应多个V，V可以组合使用，V将事件给C处理，可以单独的改变C，...通过设计以清晰的结构增强了灵活性与复用性，从而实现了表现层和逻辑层的分离。
当然，以上只是充当了所见与所想的记录而已。
没有评论:
发表评论