设计模式 - 结构型模式总结

我们介绍完了所有GOF设计模式书上的7种结构型设计模式，又到了总结的时候了。

如果回顾一下这7种结构型设计模式，我们会发现有些模式很类似。是的，从结构来看确实很像。但是我们讲设计模式很多时候是从设计者的意图来区分的，单从代码结构来看可能是很类似，但是意图完全不一样。

 

Adapter，Bridge，Facade

Adapter：目的是为了解决不同接口类库之间不能一起工作的问题。Adapter模式提供了一个适配器，2个不同接口的对象通过适配器可以一起工作。或者我们用转接口这个词更能表达意思。Adapter模式通常在类库已经存在的情况下被使用。通过一个适配器改变对象的接口，这样另外一个对象就可以通过这组新接口来使用原本不能使用的对象。所以说适配器只是改变了对象的接口（或者说改了接口名字而已），而没有创建全新的接口。

Bridge：对抽象接口和实现部分进行了分离，然后再桥接起来。Bridge模式通常在类设计之前就被考虑。刚好和Adapter相反。

Facade：Facade提供了一个全新的接口，也就是说Facade提供的接口是它的实体所没有的。比如提供一个接口，这个接口会调用一系列子系统中的对象的功能，从而使得client可以访问这个高层接口。也就是说这个高层接口是由子系统中的对象来组合实现的，但是子系统本身是没有这个接口的。 Adapter则是复用原有的接口。

 

Composite，Decorator，Proxy

从结构图看，这3种模式都很像。但是它们的意图完全不同：

Decorator：用意是使你能够不需要生成子类就可以给对象添加功能。这样就避免了产品类库的急速膨胀，而且一个Decorator可以有能力来修饰多个产品类（同一个接口）。

Composite：目的是为了使多个相关的对象能够以统一的方式处理，它的重点不是修饰，而在于表示。一个Composite对象和一个Leaf对象具有一样的接口（可以同等对待），尽管Composite里面可以包含一系列Leaf对象和其他的Composite对象。

Composite和Decorator都支持递归操作，比如组合模式的Composite对象里面可以有Composite，装饰模式的Decorator对象可以为另外一个Decorator装饰。所以有人说装饰模式是一种退化了的组合模式，有一定的道理。但是从意图来看，几乎可以说是完全不同。根据GOF的说法，Composite可以和Decorator一起工作。这个时候，系统里面有一个统一的抽象接口，这个抽象接口有一些composite子类和一些decorator子类。从Decorator模式的角度看，composite是一个ConcreteComponent，可以为这个composite进行修饰。从Composite角度来看，Decorator是一个leaf，Composite类可以组合这些Decorator类来创建一个更大的对象。

Proxy：Proxy和Decorator也很像，Proxy可以控制对一个对象的访问，Decorator可以为一个对象增加一些功能。可以看到意图完全不一样（尽管结构几乎一样）。Proxy的目的是：当直接访问一个实体不方便或不符合需要时，Proxy提供一个代理对象。比如代理模式一文中的CPicture对象，因为CPicture对象开销很多，所以我们提供一个虚代理，让大对象的创建延迟到真正需要时。而Decorator的目的是：一个实体没有需要的功能，从而给这个实体加上某些功能。Proxy模式中Proxy的实体提供关键功能，而Proxy仅仅是对实体对象的访问控制。而Decorator中的组件仅仅提供了部分功能，一个个Decorator可以提供其他功能。所以说Decorator需要支持递归（需要组合各种Decorator来提供更加完整的功能）。Proxy则对递归不是那么重视，对一个Proxy对象再进行控制的情况好像比较少见。

 

Flyweight

享元模式跟其他6种结构型模式差异比较大。享元模式目的是：在拥有大数量对象的系统中，共享对象以节省内存。

 

个人觉得，除了享元模式，其他6种结构型模式都具有一定的类似。我们需要细细体会它们的区别，而这些区别往往需要在长期的实战过程中才能领会。 限于个人能力有限，还是有很多东西我也没有搞明白。每次看设计模式这本书我都会觉得之前有些东西理解不正确。设计模式本身就是一个很抽象的东西，不同的人会有不同的理解。如果我们能从其他人的经验中获取一些对自己有用的帮助，那我们付出的学习时间也就有价值了。

另外，学习设计模式，我们可以尝试对自己做过的一些系统进行重构，往往会发现使用合适的设计模式会得到一个更好的系统架构，会让自己心情很舒畅。哈哈，至少我个人有这种感觉。当然这个需要时间。