当遇到某些任务对象A需要但是不方便自己完成,而对象B正好可以胜任这些任务时,对象A把任务交给对象B去完成就变成最佳的选择,但是,对象A这时候并不认识对象B,所以就有了代理人的角色,对象A只需要把任务清单交给代理人,然后监督代理人,代理人负责找到能够完成任务清单上任务的对象B,交给对象B去完成任务,另外,子类继承父类,同时也继承父类遵守的协议.比如保姆类遵守了BaoMuDelegate协议,她的子类女儿也遵守BaoMuDelegate协议,不用添加协议,便能帮助母亲去完成任务.(这里的代理人是委托人(对象A)的一个实例变量,与协议共同完成传递消息的任务)
补充:关于代理人的理解,代理是委托人(对象A)的一个实例变量,用来存储被委托人的对象地址如:mother.delegate = self,其实就是mother 的delegate实例变量里面放了医生对象的地址,当mother在supervice方法中调用[self.delegate cook] = [mother.delegate cook] = [doctor cook],所以在doctor中实现的cook方法就能被mother.delegate调用;总结,代理只是两个类之间传递信息的一个容器;本质上,还是方法的调用
另一个例子就是下载,NSURLConnection去进行下载了,主线程一般不能一直等着它完成下载吧。所以会需要一个controller去实现NSURLConnectionDelegate,并作为NSURLConnection的代理。这样当NSURLConnection完成下载后,就会调用后者的connectionDidFinishLoading:方法了。
(来自知乎http://www.zhihu.com/question/19827157/answer/13086213)
简单实例:
委托人
#import <Foundation/Foundation.h>
//1.声明协议(发布委托)
@protocol BaoMuDelegate<NSObject>
//协议内容(委托内容)
-(void)takeCareChild;
-(void)cook;
@end
@interface Mother : NSObject
//设置代理人
@property(nonatomic, assign) id<BaoMuDelegate>delegate;
//监督代理人
-(void)supervice;
@end
#import "Mother.h"
@implementation Mother
//实现监督代理人
-(void)supervice{
[self.delegate cook];
[self.delegate takeCareChild];
}
@end
被委托人
#import <Foundation/Foundation.h>
#import "Mother.h"
//1.找到委托人
@interface Doctor : NSObject<BaoMuDelegate>//委托协议
//接受协议
-(void)receive;
@end
#import "Doctor.h"
@implementation Doctor
//签订协议
-(void)receive{
Mother *mother = [[Mother alloc] init];
mother.delegate = self;
[mother supervice];
}
//实现协议内容
-(void)cook{
NSLog(@"我煮饭倍儿香");
}
-(void)takeCareChild{
NSLog(@"我会看孩子");
}
@end
#import <Foundation/Foundation.h>
#import "Doctor.h"
int main(int argc, const char * argv[]) {
@autoreleasepool {
Doctor *doctor = [[Doctoralloc] init];
[doctor receive];
}
return 0;
}
补充1:委托人一般是框架对象如:UIKit, AppKit(实现方法:声明一个@protocol协议包含各种委托的方法);被委托人实现各种委托方法,响应委托人并更新自身或者其他对象的状态.补充2:关于装饰者模式在不必改变原类文件和使用继承的情况下,动态地扩展一个对象的功能。它是通过创建一个包装对象,也就是装饰来包裹真实的对象。
适用性:
1. 需要扩展一个类的功能,或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能,这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。
缺点:
1. 这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。
2. 装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。
3. 装饰模式是针对抽象组件(Component)类型编程。但是,如果你要针对具体组件编程时,就应该重新思考你的应用架构,以及装饰者是否合适。当然也可以改变Component接口,增加新的公开的行为,实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。(源自百度百科)