理解协议委托者代理者问题
2015-08-16 19:56
288 查看
先举一个例子:工人想盖楼,求助建筑师
在这一句话里,谁是委托者,谁是代理者?
一般来说会认为工人是委托者,建筑师是代理者,这样说不错,但是深入考虑发现情况正好相反
并且代理和委托是可以互相转换的,正反都能说得通。
分析问题:
谁懂得盖楼的框架?答案是建筑师
谁提供盖楼的资源?答案是工人
建筑师会亲自盖楼吗?答案是否
那么谁亲自盖楼?答案是工人
所以在OC代码逻辑上,工人是代理,建筑师是委托。
步骤
1、设置一个技术协议,协议中有搬砖,摸水泥,做脚手架等方法
2、工人类必须遵守这个协议,并实现分别功能
3、建筑师类中有一个遵循技术协议的id
4、建筑师类中有一个盖楼的框架方法,在这个框架方法中会合理调用工人代理的各项技术
5、工人对象中调用建筑师对象的盖楼方法,并通过协议回调或参数将砖头,水泥,钢筋等资源传入
6、建筑师对象中合理使用工人技术方法(协议回调),在工人的技术方法中具体实现对砖头,水泥,钢筋的操作
7、最后建造好的楼通过返回值或者协议回调传出来给工人
这里的思想是:
1、
数据成对进出的情况下,谁持有未处理资源,并要获得处理后的资源,谁是代理
2、
谁有解决问题的框架,谁是委托
3、代理和委托可以有正反两种说法,怎样有利于处理数据,就怎么做
4、不需要数据成对进出的情况,正反做都一样
5、解除耦合的两处:
(1)委托者定义代理的id指针
(2)对于数据传入,必须使用协议回调或参数
对于数据传出,必须使用协议回调或返回值
禁止使用点运算符,因为如果代理的成员变量名改了,就会有耦合现象
举个无数据成对进出的例子
小孩,保姆
小孩可以做委托,保姆做代理,保姆实现带小孩玩,带小孩洗澡两个方法
保姆可以做委托,小孩做代理,小孩实现和保姆玩,和保姆洗澡两个方法
tableView的source资源代理的实现
xml解析的实现
都是谁处理数据谁做代理,而后面封装的框架是委托,委托是架构师设计的,
代理是程序员实现的
【重点】
委托者+协议 就可以完成一个抽象的功能,只要设置一个满足协议的代理者,
实现协议中的方法,就可以将抽象功能转化为具体。
写框架的时候其实就是写一个委托者和协议,从委托者作为起点,开始编写框架,
用到什么方法就在协议里定义什么方法,抽象的实现一个功能,框架完成,然后代理者
遵循并实现协议,把自己加载进框架中即可完成具体功能。
代理模式中的委托者其实是对一类问题解决流程的抽象,协议是解决流程中细节操作的抽象,只需要创建代理者解决问题即可
这个抽象的意义在于
(1)实现了代码复用,只要是这一类问题,都可以使用这个委托者方法
(2)使开发流程更简单,只要做一个代理者,实现协议方法即可
再补充一些,加深理解
有一个问题,以问题为出发点
谁实现这个问题的框架级逻辑,谁是委托,谁实现这个问题的局部逻辑,谁是代理。
数据是互相传递的。
谁触发谁是代理,谁实现谁是委托
谁调用函数吗,不能释放,谁是代理,谁只完成一个功能,完成功能后就释放,谁是委托
人要下载,人就作为实现下载功能的迅雷代理,迅雷在有人代理的情况下能下载任何东西,迅雷做完事就被释放
我要洗衣服,我就作为会洗衣服的女朋友的代理,女朋友在有玩代理的情况下能洗任何衣服,女友洗完衣服就分手
工人盖楼,工人作为实现盖楼功能的建筑师的代理,建筑师在有工人代理的情况下能盖任何楼,建筑师盖完楼就滚蛋
保姆看小孩,小孩作为实现保姆看小孩的代理,保姆在可以看任何小孩,小孩被保姆看完,保姆就走人
保姆看小孩,保姆作为实现小孩被照顾的代理,小孩可以被任何人照顾,保姆看完小孩,小孩走了,再看另一个小孩
女孩着男孩救父亲,女孩作为会救人的男孩的代理,男孩可以帮任何丢父亲的人救父亲,男孩救完父亲,男孩就可以走了,女孩和父亲过上了幸福的生活
从哪方立足开始,哪方生命周期长,哪一方就是代理;
哪方可以抽象的实现功能,用就拿来,不用就释放,哪方就是委托;
写代理的步骤
一、先写委托者
[1]定义代理协议
[2]定义代理属性
[3]在合适的时间向代理对象发送消息,调用代理属性中的方法
(我总结为实现一个功能的全局逻辑实现,这个全局是站在功能立场上说的)
二、再写代理者
[1]遵守代理协议
[2]设置代理成员属性delegate为自己
[3]实现代理方法
(我总结为实现一个功能的局部逻辑的实现,这个局部是功能立场上说的)
一般项目中,框架里提供写好了实现各种功能的委托者和代理协议,实现的是一小块一小块的功能,一个委托者就全局地实现了一个功能,这些功能是抽象化的。
我们开发的成品如果需要实现这些功能,就要作为一堆功能的代理,分别遵守这些功能的协议,实现协议中的方法,实现功能局部的逻辑,最后在委托者里组合,将委托者的功能由抽象变为具体。
程序执行过程中,要求我们写的代码一直是活的 ,而实用代理时,就要“每实现一个功能,都做如下操作:
1、遵守这个功能要求的代理协议
2、创建此功能的委托者,设置委托者的代理为自己
3、实现代理方法
然后,调用委托者的实现的“功能步骤的抽象组合”,因为代理已经实现了功能步骤的具体,所以委托者运行“功能步骤的抽象组合”时,就直接实现了具体的功能,委托者实现完具体功能之后,委托者就没有存在的意义了,释放掉委托者(委托者生命周期结束),然后代理者(我们的程序)继续执行下一个功能,遵守下一个功能的代理协议,创建下一个功能的委托者,设置委托的代理为自己,实现代理方法。。。。。
这是我对代理的理解,有不足之处,欢迎大家指正,十分感谢~
在这一句话里,谁是委托者,谁是代理者?
一般来说会认为工人是委托者,建筑师是代理者,这样说不错,但是深入考虑发现情况正好相反
并且代理和委托是可以互相转换的,正反都能说得通。
分析问题:
谁懂得盖楼的框架?答案是建筑师
谁提供盖楼的资源?答案是工人
建筑师会亲自盖楼吗?答案是否
那么谁亲自盖楼?答案是工人
所以在OC代码逻辑上,工人是代理,建筑师是委托。
步骤
1、设置一个技术协议,协议中有搬砖,摸水泥,做脚手架等方法
2、工人类必须遵守这个协议,并实现分别功能
3、建筑师类中有一个遵循技术协议的id
4、建筑师类中有一个盖楼的框架方法,在这个框架方法中会合理调用工人代理的各项技术
5、工人对象中调用建筑师对象的盖楼方法,并通过协议回调或参数将砖头,水泥,钢筋等资源传入
6、建筑师对象中合理使用工人技术方法(协议回调),在工人的技术方法中具体实现对砖头,水泥,钢筋的操作
7、最后建造好的楼通过返回值或者协议回调传出来给工人
这里的思想是:
1、
数据成对进出的情况下,谁持有未处理资源,并要获得处理后的资源,谁是代理
2、
谁有解决问题的框架,谁是委托
3、代理和委托可以有正反两种说法,怎样有利于处理数据,就怎么做
4、不需要数据成对进出的情况,正反做都一样
5、解除耦合的两处:
(1)委托者定义代理的id指针
(2)对于数据传入,必须使用协议回调或参数
对于数据传出,必须使用协议回调或返回值
禁止使用点运算符,因为如果代理的成员变量名改了,就会有耦合现象
举个无数据成对进出的例子
小孩,保姆
小孩可以做委托,保姆做代理,保姆实现带小孩玩,带小孩洗澡两个方法
保姆可以做委托,小孩做代理,小孩实现和保姆玩,和保姆洗澡两个方法
tableView的source资源代理的实现
xml解析的实现
都是谁处理数据谁做代理,而后面封装的框架是委托,委托是架构师设计的,
代理是程序员实现的
【重点】
委托者+协议 就可以完成一个抽象的功能,只要设置一个满足协议的代理者,
实现协议中的方法,就可以将抽象功能转化为具体。
写框架的时候其实就是写一个委托者和协议,从委托者作为起点,开始编写框架,
用到什么方法就在协议里定义什么方法,抽象的实现一个功能,框架完成,然后代理者
遵循并实现协议,把自己加载进框架中即可完成具体功能。
代理模式中的委托者其实是对一类问题解决流程的抽象,协议是解决流程中细节操作的抽象,只需要创建代理者解决问题即可
这个抽象的意义在于
(1)实现了代码复用,只要是这一类问题,都可以使用这个委托者方法
(2)使开发流程更简单,只要做一个代理者,实现协议方法即可
再补充一些,加深理解
有一个问题,以问题为出发点
谁实现这个问题的框架级逻辑,谁是委托,谁实现这个问题的局部逻辑,谁是代理。
数据是互相传递的。
谁触发谁是代理,谁实现谁是委托
谁调用函数吗,不能释放,谁是代理,谁只完成一个功能,完成功能后就释放,谁是委托
人要下载,人就作为实现下载功能的迅雷代理,迅雷在有人代理的情况下能下载任何东西,迅雷做完事就被释放
我要洗衣服,我就作为会洗衣服的女朋友的代理,女朋友在有玩代理的情况下能洗任何衣服,女友洗完衣服就分手
工人盖楼,工人作为实现盖楼功能的建筑师的代理,建筑师在有工人代理的情况下能盖任何楼,建筑师盖完楼就滚蛋
保姆看小孩,小孩作为实现保姆看小孩的代理,保姆在可以看任何小孩,小孩被保姆看完,保姆就走人
保姆看小孩,保姆作为实现小孩被照顾的代理,小孩可以被任何人照顾,保姆看完小孩,小孩走了,再看另一个小孩
女孩着男孩救父亲,女孩作为会救人的男孩的代理,男孩可以帮任何丢父亲的人救父亲,男孩救完父亲,男孩就可以走了,女孩和父亲过上了幸福的生活
从哪方立足开始,哪方生命周期长,哪一方就是代理;
哪方可以抽象的实现功能,用就拿来,不用就释放,哪方就是委托;
写代理的步骤
一、先写委托者
[1]定义代理协议
[2]定义代理属性
[3]在合适的时间向代理对象发送消息,调用代理属性中的方法
(我总结为实现一个功能的全局逻辑实现,这个全局是站在功能立场上说的)
二、再写代理者
[1]遵守代理协议
[2]设置代理成员属性delegate为自己
[3]实现代理方法
(我总结为实现一个功能的局部逻辑的实现,这个局部是功能立场上说的)
一般项目中,框架里提供写好了实现各种功能的委托者和代理协议,实现的是一小块一小块的功能,一个委托者就全局地实现了一个功能,这些功能是抽象化的。
我们开发的成品如果需要实现这些功能,就要作为一堆功能的代理,分别遵守这些功能的协议,实现协议中的方法,实现功能局部的逻辑,最后在委托者里组合,将委托者的功能由抽象变为具体。
程序执行过程中,要求我们写的代码一直是活的 ,而实用代理时,就要“每实现一个功能,都做如下操作:
1、遵守这个功能要求的代理协议
2、创建此功能的委托者,设置委托者的代理为自己
3、实现代理方法
然后,调用委托者的实现的“功能步骤的抽象组合”,因为代理已经实现了功能步骤的具体,所以委托者运行“功能步骤的抽象组合”时,就直接实现了具体的功能,委托者实现完具体功能之后,委托者就没有存在的意义了,释放掉委托者(委托者生命周期结束),然后代理者(我们的程序)继续执行下一个功能,遵守下一个功能的代理协议,创建下一个功能的委托者,设置委托的代理为自己,实现代理方法。。。。。
这是我对代理的理解,有不足之处,欢迎大家指正,十分感谢~
相关文章推荐
- 互联网营销之痛:全世界的牛逼都让你吹了,却要整个90后买单
- 九度oj 1053
- c++ Constructor FAQ 继续
- 动态分配内存的初始化
- 前台之boostrap
- hdu 1864 最大报销额 动态规划
- uC/OS-II 函数之信号量相关函数
- LightOJ 1047-Program C
- hdu 1850 Being a Good Boy in Spring Festival(Nimm Game)
- Scala入门到精通——第二十八节 Scala与JAVA互操作
- scala实现设计模式之装饰者模式
- Android实战简易教程-第三十七枪(ListView中点击button跳转到拨号界面实例)
- struts_ognl详解
- web_reg_save_param在飞机订票中的例子
- 电子书下载网站整理
- <input value="hidden">的作用
- scala实现装饰者模式
- NOIP2010 关押罪犯 (二分答案+二分图染色)
- 火灾面前,机器人和无人机如何拯救人类?
- 适配器模式