【问题标题】:Declaring a delegate protocol声明委托协议
【发布时间】:2012-07-08 18:28:06
【问题描述】:

我想知道在同一个类中声明protocol和在单独的文件中声明有什么区别;示例:

#import <UIKit/UIKit.h>

@class MyClassA;

@protocol MyDelegate <NSObject>

@required
- (MyClassA*)myMythod;

@optional
- (void)anOtherMethod:(NSString*)ID;

@end

@interface MyClassB : UIViewController <UITableViewDataSource, UITableViewDelegate>

@property (nonatomic, assign) id <MyDelegate> delegate;
......

这里我在与 MyClassB 相同的文件中声明协议委托,我可以在单独的源文件中声明它(协议委托)。在与类相同的文件中声明它和在单独的文件中声明它有什么区别?谢谢!

【问题讨论】:

    标签: iphone objective-c ios


    【解决方案1】:

    肯定有细微的差别。

    如果您正在谈论的协议是一个特定类使用的委托,例如MySpecialViewControllerMySpecialViewControllerDelegate,那么您可能非常希望保留声明两者都在同一个标​​题中。例如,如果另一个类要实现该协议,它可能会在逻辑上依赖于MySpecialViewController 类。因此,您不会引入任何额外的依赖项。

    但是,使用协议还有另一个重要原因(至少)。您可能正在尝试解耦两个类之间的双向依赖关系。当然,编译器不会让两个标头#import 相互连接。但是,即使您将一个类的 #import 移动到 .m 文件中,让两个类都完全了解彼此的完整 API 往往是设计不佳的标志。

    一种 稍微解耦这种关系的方法是让一个类仅通过另一个类实现的协议知道另一个类。也许Parent 拥有并创建Child 类,因此必须#import "Child.h"。但是,Child 还需要调用Parent 上的foo:bar: 方法。你可以发一个FooProtocol

    @protocol FooProtocol
      - (void) foo: (int) arg1 bar: (BOOL) arg2;
    @end
    

    然后在 Parent.h 中:

    @interface Parent : SomeBaseClass<FooProtocol> {
    }
    

    允许Child 这样做:

    @interface Child {
    }
    @property (assign) id<FooProtocol> fooHandler;
    

    并使用它

    [fooHandler foo: 1 bar: YES];
    

    这使孩子没有直接依赖于Parent 类(或Parent.h)。但是,只有在 FooProtocol.h 中而不是 Parent.h 中保留 FooProtocol 的声明时,这才有效。同样,如果这个FooProtocol 只被Child 使用过,那么将它 保留在 Child.h 中是有意义的,但如果这个协议被其他类使用则可能不是比Child

    因此,总而言之,如果您希望最大程度地分离类之间的相互依赖关系,或者鼓励在设计中更好地分离,请将您的协议保留在单独的标头中

    【讨论】:

      【解决方案2】:

      没有区别。这只是你喜欢如何组织标题的问题。

      例如,我喜欢将与“一个功能实体”相关的所有内容(无论这意味着什么,定义各不相同 :-))都保存在一个文件中。因此,使用实现协议的委托的类将在同一个标​​头中声明类和协议,因为它们几乎只是同一建筑物的不同砖块。

      【讨论】:

        【解决方案3】:

        将协议放在单独的头文件与类的头文件之间的唯一区别是它允许将协议包含为可选的,这有助于解决任何命名冲突,但为协议添加前缀应该是解决方案.

        约定似乎是在类的头文件中包含相关协议,因为这样可以更有条理并保持在一起,但是如果您有非常大的协议,将它们放在单独的文件中可能更有意义,以便使您的课程标题更易于阅读。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2023-03-27
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2021-03-14
          相关资源
          最近更新 更多