2004-08-30
结构型模式：描述的是一系列将类和对象进行组合，以构建更大的类和对象。其强调的是结构化的方式，而不是怎样去构造这些类。
结构型模式分为两种：
a、结构型类模式：通过接口或类的继承来实现。
b、结构型对象模式：不是对类或接口，而是对对象进行组合。
/*****************************************************************************************/
1、Adapter(适配器)/wrapper(包装器)
适配模式最重要的作用是去将已有的、但是接口不兼容的东西接入到系统中来。进行复杂逻辑程序的有效重用。
这个模式中adaptor,adaptee的基类是具有惟一性的。
a、类适配
类适配就是通过继承这种静态的方式来进行适配，也就是适配器会继承需要被适配的东西，
缺点是适配的范围比较小，不能满足同时适配一组对象（类及其子类）的要求。
b、对象适配
对象适配：适配器并不会静态的继承，而会是采用引用需要被适配类的方式，这样，被适配类及其子类都可以被适配了，
缺点：需要动态的指定被适配对象，而且容易引起运行期错误
注：可能是对于其他面向对象语言的不了解，我觉得用对象适配就可以了，没有必要使用类适配的模式，对于只有一个需要适配的类的情况，我们只需要将动态构造引用对象的过程加在适配器的构造函数中就可以了，在今后对其他类型的OO语言有了了解之后，可以再回顾一下此处。
/*****************************************************************************************/
2、bridge(桥接)/(Handle/boby)－－－结构型对象模式
桥接的模式最重要的作用是将抽象/表现与实现相分离，保持程序良好的可扩展性。
这个模式中window和windowimpl这两个接口是具有惟一性的。
一个一般的继承模式的设计
window--xwindow
pmwindow
iconwindow--pmiconwindow
xiconwindow
这种树状的继承方式将抽象的表现部分iconwindow和抽象的实现部分(xwindow,pmwindow)集成到了一起。
而这两者其实负责不同的东西，一是表现(外部特征，如icon是可以拖拽的，是由矩形组成的等等)，二是具体实现平台，负责在xwindow风格下的线如何画，线有多粗，从什么位置开始画等等。
于是应该有着两条线的结构：
window--iconwindow
applicationwindow
windowimpl--xwindow
pmwindow
中间通过window对windowimpl的引用来达到桥接的作用，也就是说，桥接的奥秘就在于此，合理的将这两者的接口进行分离，是桥接模式设计的关键。
桥接方式的退化形式就是我们只是需要实现xwindow或者pmwindow中的一种，这样windowimpl就失去意义了。（对于有些语言，windowimpl的存在可能有利于实现的改变不需要重新编译客户应用程序）
/*****************************************************************************************/
3、composite(组合)－－－结构型对象模式
组合模式使得单个对象和组合对象的使用具有一致性。使得对外提供的接口变得单一，用户忽略单个对象与组合对象的差异。
组合模式着力于解决这样一个矛盾：
在一个程序组中有着层次的关系，需要表现（这是一个内部重用性和易读性的问题）
但是这个程序组中的对象有着共性，并且希望外部调用程序忽视其各异性而只是关注其共性的部分（这是一个外部接口简单化的问题）。
所以其主要元素的关系就是这样了：
composite(复合对象)-leaf(简单对象)
composite(复合对象)-leaf(简单对象)
leaf(简单对象)
而这些对象实现统一的接口或者抽象类：compositeInterface;任何client对任何对象实例的操作都是通过接口进行。
模式的实现：
在实现中会有一系列的问题，这只是实现的问题，和模式本身无关。
1、显示父对象引用：解决方法：建立一个稳定，模式化的父子引用关系和操作方法。
2、共享组件：这将父子之间的1：N的关系变成了N：N的模式，参考flyweight模式。
3、最大化component接口：这是保证操作透明化的必须，我们应该尽力达到这个目的。
4、声明管理子部件的操作：这个问题最大的麻烦来源于子部件和父部件最大的差异－－有没有子节点，可以通过统一的，技巧性的add,remove方法来完成。
5、compositeInterface是否应该实现一个compositeInterface列表：这是一个关于存储的问题，就是对于子节点的引用对于叶子节点是无意义的内存消耗。
6、子部件排序：Iterator模式应该有一定的作用。
7、高速缓存改善性能。
/*****************************************************************************************/
4、decorator(装饰)/包装器(wrapper)－－－结构型对象模式
从名字我们就可以看出这个模式的基本立意：一位画家画完一幅画（实现一个组件）之后，并不需要自己去做画框（decorator）,做这个画框就是这个模式需要解决的问题。
可以看到画框能为画家所用是基于一种前提的，就是画家的用纸和画框的大小是符合的，也是基于一种结果，就是画还是画，不会因为画框而改变其画的本质和内容，只是现在是一幅有框的画了。
回到模式中，我们可以看到这个模式的大概了：
component(组件接口)－concreteComponent(组件实现)
－decorator(装饰器)－－>m_cmp(对组件实现的引用)
这里我们可以看到decorator模式和adaptor模式的区别，decorator着力于装饰器部分的重用，而adaptor只是着力于组件的重用。decorator着力于封装组件的可以插件化的共性特征，其着眼点是组件级别以下的功能重用。adaptor着眼的还是组件一级的功能重用。
/*****************************************************************************************/
在前面的composite和decorator模式中，我们不停的追求将组件实现得更加的细粒度化，以便增加组件的可重用性，这基本是各种良好设计的共同特征。
但是这种设计方式也会导致各种问题，其中就包括零散、以及大量对象实例导致的资源消耗问题。
/*****************************************************************************************/
5、facade(外观)－－结构型对象模式
facade模式最大的特点就是将复杂、零散的子系统进行唯一入口的封装。
这种模式在我经历的系统印象最深的就是多层分层的层层之间的接口上，一个唯一的入口，让层次非常的清晰。
其实这种模式与adaptor有一定的相似之处，都是屏蔽两个不同的子系统，但是不同的是，facade是主动的构建，而adaptor是为了接入其他的系统而被动的构建的，可以看出，要对一个已经实现了facade模式的子系统构建adaptor远比没有没有实现facade模式的要简单的多，代价要小得多。
/*****************************************************************************************/
6、flyweight(享元)－－结构型对象模式
享元设计模式着力解决的就是当内存中存在大量同样的对象实例导致的资源消耗问题。
可以几个方面来理解，
享元模式追求的是实例级别的重用。
将外部状态（上下文）和对象实例本身分离，不是在构建时传入外部状态，而是在运行期，甚至这种状态完全是过程性的，和对象实例没有关系。而内部状态只在创建时指定，而在运行期是绝对不可以碰的。
这种模式与原型模式的最大区别在于，一个共享实例级别的，一个是共享类的级别。
/*****************************************************************************************/
6、proxy(代理)/surrogate－－结构型对象模式
常见使用情况
1、远程代理（remote proxy）
2、虚代理(virtual proxy)：根据需要创建开销很大的对象。
3、保护代理（protection proxy）：控制对原始对象的访问。
4、智能指引（smart refrence）：取代简单指针，便于在访问对象前做些附加操作。
这种代理使用广泛，什么copy_on_write,lazy_loading等技术都可以考虑这种方式的实现。
proxy模式代理和被代理对象接口是一致的或者是子集，但adaptor模式则不同。
decorator模式为对象增加接口，而proxy是转发或者限制接口。