目标-c异步通信:目标/动作还是委托模式？

Question

我正在处理一些异步通信情况(事件驱动的XML解析、NSURLConnection响应处理等)。我试着简单地解释一下我的问题：

在我的当前场景中，有一个服务提供者(可以与xml解析器对话或做一些网络通信)和一个客户端可以要求服务提供者异步地执行它的一些任务。在这种情况下，当服务提供者完成其处理时，它必须将结果返回给客户端。

我试图找到一种模式或经验法则来实现这类事情，我看到了3种可能的解决方案：

1.使用委托模式：客户端是服务提供者的委托，它将在任务完成时接收结果。

2.使用目标/动作方法：客户端要求服务提供者执行任务，并传递服务提供者完成任务后必须调用的选择器。

3.使用通知。

(更新)经过一段时间的尝试解决方案#2 (目标和行动)，我得出的结论是，在我的情况下，最好使用委托方法(#1)。以下是每种选择的利弊，就我所见：

委托方法：

• 1 (+)选项1的优点是我们可以检查编译时错误，因为客户端必须实现服务提供者的委托协议。
• 1 (-) protocol.
• 1 (-)--这也是一个缺点，因为它导致客户端与服务提供者紧密耦合，因为它必须实现其委托protocol.
• 1 (+)，它允许程序员轻松浏览代码并找到客户端的方法，服务提供者从客户端的角度调用以传递其results.
• 1 (-)，一旦得到结果，就很难找到服务提供者将调用哪种方法。仍然很简单，只需转到委托协议方法就可以了，但是第二种方法是更多的direct.
• 1 (-)我们必须编写更多的代码:定义委托协议并实现it.
• 1 (-)，而且应该使用委托模式来委派行为。从语义上讲，这个场景并不是一个确切的委托案例。

动作/目标逼近

• 2 (+)选项2的优点是，当调用服务提供者方法时，还必须指定指定回调操作的@选择器，因此程序员知道将调用哪个方法来处理与此相反的results.
• 2 (-)，因此很难在浏览服务提供程序代码时在客户端中找到将调用哪种方法。程序员必须进入服务调用，并查看哪个@selector正在被传递给along.
• 2 (+) --这是一个更动态的解决方案，并且减少了parts.
• 2 (-)之间的耦合--可能是最重要的事情之一：会导致运行时错误和副作用，因为客户端可以传递一个不存在于服务提供者的选择器。使用简单和标准方法的
• 2 (-) (#执行器选择器:withArgument:withArgument：)服务提供者只能传递最多2个参数。

Notifications:

• 我不会选择通知，因为我认为在需要更新多个对象时应该使用通知。此外，在这种情况下，我想直接告诉委托/目标对象在生成结果之后应该做什么。

结论：在这一点上，我将选择委托机制。这种方法提供了更多的安全性，并允许轻松浏览代码，以跟踪向委托发送服务提供者操作结果的后果。这个解决方案的负面方面是:它是一个更静态的解决方案，我们需要编写更多的代码(与协议相关的内容)，而且，从语义上讲，我们并不是真正谈论委托，因为服务提供者不会委派任何东西。

我是不是遗漏了什么？你有什么建议，为什么？

谢谢!

Answer 1

你确实错过了第三种选择-通知。

您可以让客户端观察服务提供者发出的通知，指示它有可用的新数据。当客户端收到此通知时，它可以使用来自服务提供者的数据。

这允许很好的松耦合；不过，有些决定只是取决于您是否需要一个推拉系统。

Answer 2

很好的问题。

我认为我还没有资格(因为我是个新手)来评论哪一种设计模式比另一种更好。但我只想说，您在第2点(运行时异常)中提到的缺点可以通过以下方式避免

if([delegate respondsToSelector:callback]){
    //call to callback here
}

希望这有助于权衡各种选择

Answer 3

委托方法的另一个缺点是:服务提供者只能有一个委托。如果您的服务提供者是单个的，并且您有多个客户端，则此模式不起作用。

这使我赞成采取行动/目标办法。我的服务提供者持有状态，并在多个客户端之间共享。