为何Objective-C类与协议可同名而Swift不可？语言实现差异解析

这个问题问到点子上了！核心原因其实是两种语言在类型系统设计、命名空间机制以及设计理念上的本质差异，咱们掰开揉碎了说：

一、Objective-C：动态灵活的双类型体系 #

Objective-C能允许类和协议同名，主要有两个关键原因：

• 类与协议是完全独立的类型体系：在OC的运行时中，类是Class类型的元数据，协议是Protocol类型的元数据，两者存储在不同的区域，编译器和运行时查找它们的路径完全分开。比如你写<NSObject>时，编译器明确知道要找协议；写NSObject *obj时，找的是类，根本不会混淆。
• 前缀式命名空间，而非类型级区分：OC没有模块级的命名空间，靠前缀（比如NS、UI）来避免全局命名冲突，所以不需要通过“类型种类”来区分同名标识。只要运行时能分别找到类和协议的定义，就不会有问题。

举个实际的代码例子，完全能正常编译运行：

// 声明同名的协议和类
@protocol Demo <NSObject>
- (void)run;
@end

@interface Demo : NSObject <Demo>
@end

@implementation Demo
- (void)run {
    NSLog(@"Running!");
}
@end

// 使用时毫无歧义
Demo *obj = [[Demo alloc] init];
[obj run]; // 正确调用协议方法

二、Swift：静态安全的统一类型空间 #

Swift直接禁止这种同名情况，根源在于它的设计目标是静态类型安全，具体体现在：

• 所有类型共享同一命名空间：不管是类、协议、结构体还是枚举，都属于同一个命名空间下的“类型标识符”。编译器在解析名字时，只会看标识符本身，不会区分它是哪种类型。如果出现同名的类和协议，编译器根本无法判断你引用的是哪一个，直接就会抛出“Ambiguous use of 'XXX'”的错误。
• 零容忍的歧义设计：Swift从设计之初就强调代码的明确性，这种同名的情况会大幅增加代码的理解成本，甚至可能埋下运行时的隐患。比如你写let item: Demo = ...，编译器不知道你是要一个遵循Demo协议的实例，还是Demo类的实例，所以直接从编译阶段就禁止这种操作。

试试写下面的Swift代码，编译器会立刻报错：

protocol Demo {
    func run()
}

class Demo { // 报错：Invalid redeclaration of 'Demo'
    func run() {
        print("Running!")
    }
}

三、两者核心实现差异总结 #

内容的提问来源于stack exchange，提问作者TBXark VFanx