结构型模式讨论(Discussion of Structural Patterns)
你可能注意到各个结构型模式之间的类似，尤其是在他们的参与者(participants)及合作(collaborations)。可能是因为结构型模式依赖程序语言某些小部分机制以结构化程序代码及对象。单一或多重继承以实现类型(class-based)模式，而对象组合(composition)以实现对象型模式。但这些类似点掩盖了这些模式不同的目的(intent)。在这一小节中我们要比较对照结构型模式群组让你了解他们的个别优点。
接合器模式(Adapter)对 桥接模式(Bridge)
接合器模式(Adapter)与桥接模式(Bridge)有某些共同的特性，两者都提供一个间接的层次(a level of indirection)给其它对象以达到弹性的目的。两者参与经由一个接口传递请求给这个对象而非其拥有者。
两者之间主要的差异在于他们的目的。接合器着重在解决两个已存在接口之间的不兼容问题。而非界面如何实现；也不考虑他们可能如何独立发展。它是让两个独立设计的类共同工作而无须重新实现两者中任何一个的方式。桥接模式；从另一方面来看；连接一个抽象及其（潜在众多的）实现，它提供一个稳定可靠的接口给使用端甚至让你改变实现它的类。同时在系统持续发展下提供新实现的方便性。
由于这些差异；接合器模式与桥接模式在软件生命周期中使用在不同的时点，接合器模式在当你发现两个不兼容的类必须共同工作时便需要使用；一般可以避免重置(replicating)程序代码。而其耦合(coupling)是无法预测的。相对的使用桥接模式可以直接了解的；一个抽象必须有多种实现，而两者可以独立的发展。接合器模式在他们设计完成后可以工作，桥接模式则在他们之前。但这并不代表接合器模式次于(inferior)桥接模式，两者处理的问题是不一样的。
你可能想到外观模式(Facade)是一组其它对象的接合器，但是这种说法忽略到外观模式定义一个新的接口，而接合器再使用一个旧有接口。记住；接合器让两个已存在的接口共同工作而非定义一个全新的接口。
复合模式(Composite)对 装饰者模式(Decorator)对 代理模式(Proxy)
复合模式与装饰者模式有着类似的结构图，基于这个事实；两者依赖递归结合(recursive composition)以组织开放数量的对象。这个共通性可能引诱你把装饰者模式是复合模式的退化(degenerate)，但这是误会装饰者的重点，类似点是递归结合不同点则是在于他们的目的。
装饰者模式是设计来附加责任给对象而无须再设计子类。它避免因潜在的要去涵盖所有结合责任以致使子类扩张，复合模式有不同的目的，他着重在结构化类而可以许多相关的对象可以以一致的方式对待，同时可以以同一种方式操作许多对象犹如一个一般。它的重点是并非装饰(embellishment)而是代表(representation)。
这些目的是有所区别但是互补的(complementary)；因此复合模式与装饰者模式两者可以同时(in concert)使用的。两者的设计方式是让你构建应用系统时只是含入(plugging)对象而无须重新定义新的类。这样会有一个抽象类拥有某些复合模式子类及某些装饰者模式子类；以及某些实现系统基础的建设部分(fundamental building blocks)。此时复合模式及装饰者模式会有共同的接口。从装饰者模式的观点；复合模式是一个具体组件(ConcreteComponent)，而从复合模式的观点；装饰者是一个叶节点(Leaf)。当然他们不一定要同时使用而且就如我们前面看到的；他们的目的是全然不同的。
其它模式的结构类似装饰者的是代理，两个模式都是提供对象的一个间接层次(a level of indirection)；同时两者的实现的对象参考到其它对象以传递请求。再次；他们的目的是不同的。
就像装饰者模式，代理模式组合(compose)一个对象并提供一个可供辨识(identical)的接口给使用端，与装饰者模式不同的是代理模式并不考虑动态附加(attaching)或移除(detaching)属性，也不是设计用来递归组合。代理的目地是当其代理对象不方便或不必要直接存取时提供其代理对象一个替身(stand-in)；例如可能因为其代理对象可能是一个存活在远程机器中，有存取的限制或是不变的(persistent)。
在代理模式中，其代理对象定义关键功能而代理提供存取或参考它。在装饰者；组件只是部分的功能，其余的就是一或多个修饰的功能。装饰者满足一个状况；当一个对象的所有功能可以在编译期决定；至少不是很方便的。他的开放(open-endedness)使得递归复合成为装饰者模式基本。在代理则否；因为代理重视一个关系；即代理跟他代理的对象之间的关系，而且者个关系是可以静态的传递。
这些差异是很明显的，因为他们他们解决对象导向设计的特殊问题。但这并不代表这些模式无法结合。你可能展一个代理修饰者(proxy-decorator)为代理附加功能，或者修饰者代理(decorator-proxy)以修饰一个遥控对象。虽然这些混种(hybirds)可能是有用的（暂无实际例子），把他们分割(divisible)成模式是有用的。
2001/3/2
顶