结构模式应用总结

估计有高人一看就会对图中有些地方作出过度设计的判断，或是其它处理不妥当的地方：）。没关系，正如开头提到的本文旨在总结设计模式中结构模式的应用，所以上图是为了尽可能全的呈现结构模式下所有模式应用而刻意做了一些额外的考虑。

为了能够突出每个结构模式在上图的应用，请见下图：

代理和装饰器(红色框)

DeviceManagerSecurityProxy实现了DeviceManager接口，同时也持有一个DeviceManager的实现对象的引用，目的是在委派给真正的DeviceManager的实现对象执行设备管理操作之前，需要实现执行权限验证的操作，以确定此次调用是合法的。

装饰器和代理很容易混淆，就因为它们在代码的实现上完全一样，区别仅仅在于模式解决的问题域不同：代理在于控制被代理的对象；装饰器则是增强被装饰对象的能力或行为。我倒是觉得，在实际应用中没有必要在区分二者上让自己抓狂，毕竟代码的实现结构没有什么区别，何必在乎它的叫法呢？

适配器(绿色框)

DeviceManager定义了addDevice的方法，其实现恰好可以复用DeviceFactory的factory方法以创建一个Device的实例，那么这里的AbstactDeviceManager就担当了适配器的角色。这里是一个对象适配器模式的实现。

桥梁(橙色框)

DeviceManager抽象了设备管理的行为，但像启动、停止设备的操作是需要Device的实现类进行底层实现的，这正如桥梁模式的用意——“将抽象化和实现化脱耦，使得二者可以独立变化”。

合成(紫色框)

在设备管理的界面上，通常习惯用树形目录来呈现设备单元。每个设备自然就是树叶，当然为了方便管理，我们需要逻辑设备(LogicalDevice)这样类似设备组的概念，它关联一到多个物理设备，也就成了一个树节点。这样，当有需要对同一组设备进行操作的时候，也就只用操作逻辑设备就行了。这里是个安全式合成模式的实现。

亨元(黑色框)

这是结构模式中最为复杂的一个模式，主要用意在于共享对象实例，减少内存消耗。这里通过亨元模式来避免对统一设备的重复添加，尽管这样应用亨元模式有点牵强：P。
不过个人觉得，亨元模式的核心在于控制对象的创建，为什么GOF要将它列为结构模式的一种，这让我有点迷惑。

门面

图中貌似没有标出门面模式的应用，其实它的应用体现就是DeviceManager，它是设备管理子系统的统一接口，外部系统只需要通过它就可以享受所有设备管理子系统提供的服务了。

小结

结构模式可归结为两个关键字：

• 接口           接口明确规定了系统(或模块)的结构；
• 复用扩展   基于接口进行对复用原有组件的基础上添加新的行为，或是对原有行为的一种组合应用。