模式二：委托模式

梗概 
        委托是对一个类的功能进行扩展和复用的方法。它的做法是：写一个附加的类提供附加的功能，并使用原来的类的实例提供原有的功能。  

场景 
       扩展和复用一个类的功能常用的一种方法是继承，而另一种更普遍的方法则是委托。在很多情
况 下委托很适用，而继承则并不适用。公有继承表现的设计思想是“is-a-kind-of”，私有继承表现的设计思想则是“is-implemented- in-terms-of” ，这些关系都是静态的、不能在运行时改变的。而在一些情况下我们需要表现的设计思想是“is-a-role-played-by”的关系，在这些情况下不 应该用继承的方法。

约束 
       如果你发现一个对象需要在不同的时间“成为”不同的衍生类， 那么首先这个对象根本不应该“是”一个衍生类。因为一个对象一旦作为衍生类被创建出来，它就只能是这个衍生类的实例而不能扮演其他角色了。另一方面，一个 对象可以在不同的时间把不同的行为委托给不同的对象。

        如果你发现一个衍生类在试图隐藏其超类的方法或变量，这说明这个类根本不应当从这个超类衍生得到，因为根本没有什么合理的理由来隐藏超类的方法或变量。但另一方面，如果使用委托的设计方法，你就可以随意选择需要的方法或变量。
 
        把一个类设计成现有的具体类的衍生类也不是一件值得推荐的事情。 

       “不适当的继承”在实际中被如此广泛的应用，以至于可以把它们归纳成一种“反模式
（antipattern） ”了。正如上面所说的，继承一个具体类可能导致各种无法预料的问题。实际上，可
能绝大多数对类的功能的扩展和复用都不应该使用继承。

解决方案 
        委托是对类的行为进行复用和扩展的一条途径。它的工作方式是：包含原有类的实例引用，实现原有类的接口，将对原有类方法的调用转发给内部的实例引用。图4 展示了本模式的一般形式：

 
         委托的用途比继承更加广泛。 用继承能实现的对类的任何形式的扩展都可以用委托的方式完成。因此在[GoF]中也建议尽量用委托代替继承。

参与者

         Delegator（委托者）
         -  保存 Delegate的实例引用。
         -  实现Delegate的接口。 
         -  将对Delegate接口方法的调用转发给Delegate。 
          Delegate（受委托者）
         - 接受 Delegator的调用，帮助 Delegator实现其接口。  

效果 

        使用委托模式可以避免继承方法遇到的问题。另外，使用委托模式可以很容易的在运行时对其行为进行组合。
 
        委托模式的主要缺点是类之间的联系、类体系结构不如继承那样清楚明显。不过也有一些方法可以改善这些联系的清楚程度。 

        使用一致并且清楚的名称，让程序的读者可以直观的知道 Delegator和Delegate之间的联系。比如说，如果用一个类来代理一些 Widget 衍生类的创建，那么把这个类命名为 WidgetFactory 就是不错的方法。   在程序中写上适当的注释，告诉读者：这里使用委托模式。   遵循 Law of Demeter模式[GRAND99]，即：如果两个类之间只有间接联系，采用间接委托；如果有直接联系，采用直接委托。这可以减少类之间的联系数 量。   使用大家都知道的设计和编码模式。因为委托模式是很多其他模式的基础，如果在其他模式中使用委托模式，读者更容易理解。