Iphone Objective-c异步通信：目标/动作还是委派模式？

我正在处理一些异步通信情况（事件驱动的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
}

---

希望这有助于权衡选项

您确实错过了第三个选项—通知

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

---

这允许良好的松耦合；一些决定取决于你是否想要一个推拉系统。

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

---

这使我选择了行动/目标方法。我的服务提供商保持状态，并在多个客户端之间共享。

谢谢Mihirsm，你说得对，这将防止运行时错误。但是，程序员使用了错误的选择器这一事实在运行时之前是不可见的。这可能会产生副作用：再次，对更静态但更安全的委托机制来说，这是一个加号。干杯通过实现@protocol并使委托符合