Lio*_*Lio 14 iphone cocoa delegation objective-c target
我正在处理一些异步通信情况(事件驱动的XML解析,NSURLConnection响应处理等).我将尝试简要解释一下我的问题:
在我目前的场景中,有一个服务提供者(可以与xml解析器通信或进行一些网络通信)和一个可以要求服务提供者异步执行某些任务的客户端.在这种情况下,当服务提供者完成其处理时,它必须将结果传回给客户端.
我试图找到一种模式或经验法则来实现这种事情,我看到了3种可能的解决方案:
1.使用委托模式:客户端是服务提供者的委托,它将在任务完成时收到结果.
2.使用目标/操作方法:客户端要求服务提供者执行任务并传递一个选择器,该选择器必须在服务提供者完成任务后调用.
3.使用通知.
(更新)经过一段时间尝试解决方案#2(目标和行动)后,我得出的结论是,在我的情况下,最好使用委托方法(#1).以下是每个选项的优缺点,我看到它们:
授权方法:
1(+)选项1的优点是我们可以检查编译时错误,因为客户端必须实现服务提供者的委托协议.
1( - )这也是一个缺点,因为它导致客户端与服务提供商紧密耦合,因为它必须实现其委托协议.
1(+)它允许程序员轻松浏览代码并找到客户端的哪种方法,服务提供者正在调用以传递其结果.
1( - )从客户端的角度来看,一旦获得结果,找到服务提供者将调用的方法并不容易.它仍然很简单,只需转到委托协议方法,就是这样,但#2方法更直接.
1( - )我们必须编写更多代码:定义委托协议并实现它.
1( - )另外,委托模式应该用于委派行为.从语义上讲,这种情况不一定是授权的确切情况.
行动/目标方法
2(+)选项2的优点是,当调用服务提供者方法时,还必须指定指定回调操作的@selector,以便程序员知道将调用哪个方法来处理结果.
2( - )与此相反,在浏览服务提供商代码时很难找到在客户端中回调哪种方法.程序员必须转到服务调用,看看传递了哪个@selector.
2(+)这是一个更加动态的解决方案,可以减少部件之间的耦合.
2( - )也许是最重要的事情之一:它可能导致运行时错误和副作用,因为客户端可以将不存在的选择器传递给服务提供者.
2( - )使用简单和标准的方法(#performSelector:withArgument:withArgument :),服务提供者最多只能传递2个参数.
声明:
结论:此时,我会选择委托机制.这种方法提供了更高的安全性,并允许轻松浏览代码以跟踪向委托发送服务提供者操作结果的后果.关于这个解决方案的负面影响是:它是一个更静态的解决方案,我们需要编写更多的代码(协议相关的东西),从语义上讲,我们不是真正谈论委托,因为服务提供商不会委托任何东西.
我错过了什么吗？你推荐什么,为什么？
谢谢!
非常好的问题。
我认为我还没有资格（因为我是新手）来评论哪种设计模式比另一种更好。但只是想提一下，您在第 2 点（运行时异常）中提到的缺点可以通过以下方式避免
if([delegate respondsToSelector:callback]){
//call to callback here
}
希望有助于权衡选择
| 归档时间： |
|
| 查看次数： |
3443 次 |
| 最近记录： |