关于OC中委托(代理人)的理解

当遇到某些任务对象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接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。(源自百度百科)