设计模式--依然结构型

外观模式：主要为子系统的一组接口提供一个一致的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更容易使用。将细颗粒度变成粗颗粒度，细颗粒度被外观封装起来，外观对象提供给外部应用程序使之调用。

代理模式：想想WebService,AOP的实现就都明白了

A d a p t e r 模式：D e c o r a t o r模式不同于A d a p t e r模式，因为装饰仅改变对象的职责而不改变它的接口；而适配器将给对象一个全新的接口。

C o m p o s i t e 模式：可以将装饰视为一个退化的、仅有一个组件的组合。然而，装饰仅给对象添加一些额外的职责—它的目的不在于对象聚集。

S t r a t e g y 模式：用一个装饰你可以改变对象的外表；而 S t r a t e g y模式使得你可以改变对象的内核。这是改变对象的两种途径。

 

结构型模式：(GOF)

A d a p t e r模式主要是为了解决两个已有接口之间不匹配的问题。它不考虑这些接口是怎样实现的，也不考虑它们各自可能会如何演化。

这种方式不需要对两个独立设计的类中的任一个进行重新设计，就能够使它们协同工作。另一方面，B r i d g e模式则对抽象接口与它的（可能是多个）实现部分进行桥接。虽然这一模式允许你修改实现它的类，它仍然为用户提供了一个稳定的接口。 B r i d g e模式也会在系统演化时适应新的实现。A d a p t e r模式在类已经设计好后实施；而B r i d g e模式在设计类之前实施。

Decorator 旨在使你能够不需要生成子类即可给对象添加职责。这就避免了静态实现所有功能组合，从而导致子类急剧增加。 C o m p o s i t e则有不同的目的，它旨在构造类，使多个相关的对象能够以统一的方式处理，而多重对象可以被当作一个对象来处理。它重点不在于修饰，而在于表示。composites  和d e c o r a t o r将拥有共同的接口。从D e c o r a t o r模式的角度看，c o m p o s i t e是一个C o n c r e t e C o m p o n e n t。而从c o m p o s i t e模式的角度看，d e c o r a t o r则是一个L e a f。

proxy 和d e c o r a t o r对象的实现部分都保留了指向另一个对象的指针，它们向这个对象发送请求。

对于模式可以说的是，记住不要为了使用模式而使用模式，分析场景，对症下药，多用模式的组合，这些都是需要通过经验来积累的。