设计模式学习阶段性总结之结构型模式

 

结构型设计模式一共有7个，他们分别是adapter，bridge，composite，decorator，façade，flyweight，proxy。这一阶段的学习明显感觉到比创建型麻烦了，因为显然结构型涉及的类之间的关系比较复杂，而创建型则只关心类的创建问题。

 

Adapter适配器设计模式，即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。在实际的软件开发过程中，由于应用坏境的变化，常常需要将一些现存的对象放在新的坏境中使用，但是新坏境要求的接口是这些现存对象所不满足的。适配器设计模式就是为了解决这种问题而出现的。其中Adapter一共有两种形式，一种是adapter class，另一种是adapter object。Adapter模式可以实现得非常灵活，不必拘泥于上面那两种形式。例如完全可以将adapter模式中的现存对象作为新的接口方法参数，来达到适配的目的。

 

Bridge桥接设计模式，抽象不应该依赖于实现细节，实现细节应该依赖于抽象，因为抽象往往比较稳定，而实现细节则比较容易变化。Bridge模式使用对象间的组合关系解耦了抽象和实现之间固有的绑定关系。Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。Bridge模式的应用一般在两个非常强的变化维度。

 

Composite组合设计模式，如何将客户代码与复杂的对象容器结构解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？Composite模式采用树形结构来实现普遍存在的对象容器，从而将一对多的关系转化为一对一的关系，使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个对象还是组合的对象容器。

 

Decorator装饰设计模式，如何使对象功能的扩展能够根据需要来动态地实现？同时避免扩展功能的增多带来的子类膨胀问题？从而使得任何功能扩展变化所导致的影响将为最低？通过采用组合而非继承的手法，decorator模式实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的灵活性差和多子类衍生问题。Component类在decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且decorator类对于component类应该是透明—换言之component类无需知道decorator类，decorator类是从外部来扩展component类的功能。Decorator类在接口上表现为is-a component的继承关系，即decorator类继承了component类所具有的接口。但在实现上又表现为has-a component的组合关系，即decorator类又使用了另外一个component类。我们可以使用一个或者多个decorator对象来装饰一个component对象，且装饰后的对象仍然是一个component对象。Decorator模式并非解决多子类衍生的多继承问题，decorator模式应用的要点在于解决主体类在多个方向上的扩展功能—是为装饰的含义。

 

Façade外观设计模式，如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？从客户程序的角度来看，façade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种解耦的效果—内部子系统的任何变化不会影响到façade接口的变化。Façade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade很多时候更是一种架构设计模式。注意区分façade模式、adapter模式、bridge模式与decorator模式。Façade模式注重分离接口（抽象）与其实现，decorator模式注重稳定接口的前提下为对象扩展功能。

 

Flyweight享元设计模式，面向对象很好的解决了系统抽象性的问题，同时在大多数情况下，也不会损及系统的性能。但是，在某些特殊的应用中下，由于对象的数量太大，采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。采用纯粹对象放案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价—主要指内存需求方面的代价。如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明的使用面向对象的方式来进行操作？Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。

 

Proxy代理设计模式，在面向对象系统中，有些对象由于某种原因（比如对象创建德开销很大），或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。如何在不失去透明操作对象的同时来管理/控制着些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。Proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。