委托在Objective-C中查询

因此，我对代表的工作、为什么使用、如何实施等有一个不错的想法，我正在我的一个项目中实施它。我试图解决的问题是将控制器对象与网络访问类解耦。在这种情况下，这些想法在我的脑海里变得有点混乱

我直觉地认为NetworkAccessClass应该是控制器对象的委托，因为NetworkAccessClass充当控制器对象的助手。但它似乎以相反的方式工作，因为下面的方法显然是正确的：

NetworkaccessClass.h

@protocol NetworkAccessDelegate
-(void) requestSucceded:(NSData *) data
-(void) requestFailed:(int) responseCode;
@end
@interface NetworkAccessClass : NSObject
{
    id<NetworkAccessDelegate> networkDelegate;
}

@property(nonatomic, assign) id networkDelegate;

-(void) initWithDelegate:(id) delegate; //

@end

最后在my

FirstViewController.h

#import "NetworkAccessClass.h"
@interface FirstViewController<NetworkAccessDelegate>
{

}
-(void) requestSucceded:(NSData *) data;
-(void) requestFailed:(int) responseCode;
@end

#导入“NetworkAccessClass.h”
@界面视图控制器
{
}
-（无效）请求成功：（NSData*）数据；
-（void）requestFailed：（int）responseCode；
@结束

在

SecondViewController.h

中也是如此，依此类推

虽然这确实将我的控制器与网络类解耦，但我还是忍不住觉得这是错误的，因为在本例中，控制器充当网络类的委托或帮助方法，而不是相反。我缺少一些基本的东西吗？还是这样

谢谢，

---

Teja.

代理不是“助手方法”。将它们视为在发生事件时得到通知的对象。（尽管不要将它们与“通知”混淆——这完全是另一回事。）在本例中，您的网络类执行它的工作，然后在实例化并激发的视图控制器上调用其委托方法，并将该响应的内容报告给视图控制器。然后，控制器可能会用网络连接器获得的数据更新视图。经典的委托模式，就在那里。

委托不是“助手方法”。将它们视为在发生事件时得到通知的对象。（尽管不要将它们与“通知”混淆——这完全是另一回事。）在本例中，您的网络类执行它的工作，然后在实例化并激发的视图控制器上调用其委托方法，并将该响应的内容报告给视图控制器。然后，控制器可能会用网络连接器获得的数据更新视图。经典的委托模式，就在那里。

嗯，我明白了理论，但是委托，如果你只是把它看作一个英语单词，它只是把一项任务分配给某人/事，有点像助手方法，这会导致混乱。不过，您提供的类比很有帮助。好吧，就像在示例中一样，让过程的结果在结果感兴趣的地方进行本地处理，这样核心的“工作中的事情”就不必知道在UIView中放置数据的位置。委托模式允许完全解耦。这个过程所做的事情就是“委托”（动词）将其结果的处理过程委托给那些结果想要使用的对象。嗯，我明白这个理论，但是委托，如果你只是把它看作一个英语单词，那么它只是将一个任务分配给某人/事物，有点像一个助手方法，这会导致混乱。不过，您提供的类比很有帮助。好吧，就像在示例中一样，让过程的结果在结果感兴趣的地方进行本地处理，这样核心的“工作中的事情”就不必知道在UIView中放置数据的位置。委托模式允许完全解耦。流程所做的事情是将其结果的处理“委托”（动词）给靠近这些结果要使用的对象。

#import "NetworkAccessClass.h"
@interface FirstViewController<NetworkAccessDelegate>
{

}
-(void) requestSucceded:(NSData *) data;
-(void) requestFailed:(int) responseCode;
@end