在 Objective-C 开发中，协议与实现类之间的命名关系非常重要。虽然语言允许协议名和类名相同，但从可读性和维护性等角度出发，这种做法并不推荐。本文通过一个典型示例展开分析，并提供更合理的命名建议。
一、示例
在某项目中，有如下结构的协议与类：
@protocol SQIHandler <NSObject>
- (instancetype)initWithContext:(id)context;
- (void)viewDidLoad;
- (void)viewWillAppear;
- (void)viewDidAppear;
@end
@interface SQIHandler : NSObject <SQIHandler>
@property (nonatomic, assign) BOOL hasAppeared;
@property (nonatomic, weak) id context;
@end
这里 SQIHandler 同时被用于协议和类名。
二、为什么不推荐协议名与类名相同？
1. 可读性差
当你看到 id<SQIHandler>，你可能无法立即分辨它代表一个协议类型还是某个类实例。
2. 导航/补全混淆
在 Xcode 中使用跳转（如 Command+Click）或代码补全时会遇到歧义，容易跳转错误。
3. 不利于模块化与维护
在模块拆分或重构时，类名和协议名冲突会带来潜在命名冲突，增加维护成本。
三、推荐的命名方式
为了避免上述问题，推荐以下两种命名策略：
✅ 使用 -ing 结尾表示行为
@protocol SQIHandling <NSObject>
@end
@interface SQIHandler : NSObject <SQIHandling>
@end
这是 Apple 官方广泛使用的风格（如 NSCopying、UITableViewDelegate）。
✅ 使用 Protocol 后缀明确表示协议
@protocol SQIHandlerProtocol <NSObject>
@end
@interface SQIHandler : NSObject <SQIHandlerProtocol>
@end
这种方式直观清晰，也常用于代码生成或跨团队协作场景。
四、Last
| 项目 | 建议 |
|---|---|
| 协议命名 | 避免与类名相同 |
| 推荐风格 | -ing 或 Protocol 后缀 |
| 好处 | 提高代码清晰度、便于维护、减少 IDE 混淆 |
虽然语言层面允许类和协议同名，但良好的命名规范有助于降低团队协作成本，提高代码质量。
