设计模式 - 享元 & 代理

Design Pattern - FlyWeight & Proxy

FlyWeight : 以共享的方式高效地支持大量的细粒度对象。享元对象能做到共享的关键是区分 Intrinsic(共享的信息) 和extrinsic(不共享的信息) 。
Proxy : 代理和被代理的对象都继承自同一接口。但是那种HeavyJob()一般放在被代理的类中， 需要的时候再建立。

以下摘录自 http://www.idcdream.net/archive_64750.html
(1)适配器模式。这个模式理解起来非常简单，就是把类用另外一种接口封装了一次。这种模式是我们不必仅仅因为类的接口规格不标准而重写一个类。
(2)桥接模式。正如书上所说的，这种模式将抽象层和实现层分离。我的理解是它就像是函数指针。指针变量相当于抽象层，它可以指向各种版本的函数，这些函数就是实现层。我们通过改变指针的指向而改变类的工作方式。
(3)组合模式。这种模式真得很好，不论简单对象还是组合简单对象得到的复杂对象对客户来说仅仅只有一种接口。这样可以省去一大堆的switch/case。这种模式非常有利于对象的嵌套组合，可以大大简化系统。所以正如书中所说，几乎所有的面向对象的系统都有使用了组合模式。
(4)装饰模式。该模式使用了动态的组合，可以为对象动态的添加行为。但是这种模式的适用情况似乎比较少，一般在你因为某种原因无法使用继承来构造新类(使新类具有要添加的行为)的情况下使用该模式。但是这种模式有个缺点，它使得同一个类的对象却拥有不同的行为，因此该模式的使用应该有个限度。
(5)外观模式。这个模式理解起来也很简单，就是将系统接口统一集中来减少和其他系统的耦合。就像以前咱们csdn的登陆系统，以前的登陆分布在各个板块样式繁多，这时登陆系统与其他系统的耦合很大，登陆系统有变化时，分布在各个板块的登陆口都要变化。现在好了，登陆口集中到一个页面上了，登陆系统只需在这唯一的页面上作修改就可以了。
(6)享元模式。是程序支持大量的小粒度对象。现在想来可能游戏里大量的使用了这种模式。比如魔兽争霸里的某个兵种。你不可能为该兵种的每个对象都载入一次贴图。使用享元模式，只需载入一次贴图放入共享池，每个对象只保存自己特有属性即可。
(7)代理模式。为了控制对特定类的访问，我们提供一个类作为接口。这种模式应该还是比较常用的，为了使问题简单清晰，我们经常要限制客户对某些类的访问。由于代理的加入，客户可以得到更加方便和智能的类。

转载于:https://www.cnblogs.com/Dabay/archive/2006/04/12/373603.html