FLYWEIGHT(享元)
意图：
运用共享技术有效地支持大量细粒度的对象。
适用性：
1.一个程序应用了大量的对象，造成很大的存储开销。
2.对象的大多数状态可变为外部状态。
3.如果删除对象的外部状态，那么可以用相对较少的公象对象取代很多组对象。
4.应用程序不依赖于对象标识
思考：
上述的适用性和别的模式中介绍的不太一样。基本上，适合使用FlyWeight模式的场景需要同时满足上述四个条件，而别的模式大多只要满足适用性的一两条，就可能适合采用该模式。
从第一个适用性条件可以看出，这基本上属于开销优化的范围。因此，除非事先有足够的领域知识能够加以预见，否则，是不必在早期设计中考虑使用该模式的。要想成功运用该模式，必须的一个条件是：除了那些外部状态，余下的状态将是需要共享的。这也就意味着一般而言，FLYWEIGHT是只读的--变化的部分仍然需要加以分离出来－－从这个意义上来说，“享元”的中文翻译更好地表达了这层意思。一个最好的情况是，共享的这些对象没有外部状态，且只作为系统共享的只读对象。关于第四条，可以认为是一种补充说明，对象标识本身其实也是可以作为变化的部分加以分离的。
上面的讨论强调了“只读”，事实上，本模式并不要求FLYWEIGHT是只读的。但是，必须看到修改FLYWEIGHT的后果：这种影响是全局的，接近于全局变量的变种。某些时候也许我们确实需要这种全局的作用效果，但是滥用这一能力可能导致理解上的困难和程序行为的判断困难。FlyWeight的主要目的不在于此。
通常，享元也并不能当作一个纯粹的只读对象，那么，将变化的部分加以分离可能是必须的工作，也有必要对分离的效果加以评估再决定是否和如何运用FlyWeight模式。
PROXY（代理）
意图：
为其他对象提供一种代理以控制对这个对象的访问。
适用性：
书中列出了几种运用proxy的场景作为适用性的说明：
1.远程代理，为一个不在同一地址空间的对象提供局部代理。
2.虚代理，根据需要创建很大的对象。
3.保护代理控制对原始对象的访问。
4.智能引用，取代简单指针，在访问对象时提供附加操作。例如：智能指针；第一次访问持久对象时，将它装入内存；在访问一个实际对象前，检查其是否加锁。
思考：
相对于Decorator而言，通常Proxy是更重量级的。Proxy和Bridge模式也有很多相似之处：透过一个接口去访问真正实现功能的对象。Decorator和Proxy的区别在于，Decorator目标仅仅在于增加某些方法的职责，并不打算全面掌控目标对象，另外，Decorator也并不确定自己将要修饰的可能会是什么对象。Proxy模式则相反，Proxy需要全面了解甚至需要构建被代理对象，而Proxy和被代理对象之间的关系也是静态决定的。有一点是相同的：一个实际对象既可以有多个Decorator,也可以有多个Proxy。
Proxy和Bridge虽然有相似性，但是Bridge的目的仅仅是为了维持接口和实现的各自演化，Bridge模式并不打算用来支持创建非常复杂的实现。Bridge模式的接口和实现在语意上是完全一致的。而Proxy模式，虽然一般而言Proxy和被代理对象之间具备一致的接口，但这完全是不必要的。当弱化Proxy的额外处理能力，强化Decorator的职责范围，这三个模式之间的实现区别将会不那么显著，我们需要警惕的是，这三者之间的意图则是差别非常巨大的。
