类名与协议名相同，开发中应该避免吗？

在 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 混淆

虽然语言层面允许类和协议同名，但良好的命名规范有助于降低团队协作成本，提高代码质量。