委托是对一个类的功能进行扩展和复用的方法。它的做法是:写一个附加的类提供附加的功能,并使用原来的类的实例提供原有的功能。 本文提供的是一个思想,在ios中的delegate设计模式参考 http://blog.csdn.net/lovefqing/article/details/8270111 场景 扩展和复用一个类的功能常用的一种方法是继承,而另一种更普遍的方法则是委托。在很多情况下委托很适用,而继承则并不适用。另外在[MEYERS98]中也讲到,公有继承表现的设计思想是“is-a-kind-of” ,私有继承表现的设计思想则是“is-implemented-in-terms-of”[1],这些关系都是静态的、不能在运行时改变的。而在一些情况下我们需要表现的设计思想是“is-a-role-played-by”的关系,在这些情况下不应该用继承的方法。 下面用一个例子来帮助说明。假设我们为一个航空公司设计软件系统,于是我们必须用一些类来表示各种各样的“人”,包括机组人员、售票员、旅客等等。一种思路是这样:因为这些人都是抽象的“人”,因此设计一个Person抽象类,并从这个抽象类衍生出我们需要的各种类。这个设计方案的问题是很明显的:一个机组人员在休假的时候可能乘坐飞机而成为一个旅客;航空公司也可能把机组人员调去做售票员……是的,一个人可能成为三种角色中的任何一种。而且即使使用了这么多衍生类,我们仍然有困难。而一个“人”可能在不同的时间扮演不同的角色,于是我们可能需要用多个对象来表现同一个“人”的不同角色,这也是一件相当麻烦的事情。 约束 如果你发现一个对象需要在不同的时间“成为”不同的衍生类,那么首先这个对象根本不应该“是”一个衍生类。因为一个对象一旦作为衍生类被创建出来,它就只能是这个衍生类的实例而不能扮演其他角色了。另一方面,一个对象可以在不同的时间把不同的行为委托给不同的对象。如果你发现一个衍生类在试图隐藏其超类的方法或变量,这说明这个类根本不应当从这个超类衍生得到,因为根本没有什么合理的理由来隐藏超类的方法或变量。但另一方面,如果使用委托的设计方法,你就可以随意选择需要的方法或变量。把一个类设计成现有的具体类的衍生类也不是一件值得推荐的事情。继承一个具体类可能导致各种无法预料的问题。实际上,可能绝大多数对类的功能的扩展和复用都不应该使用继承。 解决方案 委托是对类的行为进行复用和扩展的一条途径。它的工作方式是:包含原有类的实例引用,实现原有类的接口,将对原有类方法的调用转发给内部的实例引用。委托的用途比继承更加广泛。用继承能实现的对类的任何形式的扩展都可以用委托的方式完成。因此在[GoF]中也建议尽量用委托代替继承。 实现 委托模式的实现是非常直接的。Delegator保存Delegate的实例引用,并转发相应的方法调用。