在 Objective-C 中，我通常会看到返回动态类型对象的方法，定义如下：
- (id)someMethod:(id)someParameter;
不过，我知道我也可以做到这一点：
- someMethod:someParameter;
有趣的是，我在更多核心级别的基础课程中看到了后一种约定，但其他人似乎都使用第一种。既然 Objective-C 运行时推断出一个无类型的方法或参数将返回id，我为什么要包含它？它不会破坏阅读的流程吗？
我不仅想知道开发人员考虑使用此约定可能出现的问题，而且还想知道你们是否认为这很奇怪？
由于该语言允许两种形式，因此它确实是一种风格。鉴于此，Objective-C 非常依赖于可读性而不是简洁性，大多数开发人员更喜欢第一个 ( -(id)someMethod)，因为它明确了返回类型。
与您的问题没有直接关系，但id不是动态类型的。它是一个指向 Objective-C 对象的指针。由于在 Objective-C 中消息分发是动态的，id因此通常可以将其视为动态类型，但实际上它仍然是静态类型。换句话说，Objective-C 是动态绑定但静态类型的。
首先，我相信是编译器推断类型，而不是运行时。
我相信第二个约定来自于 Objective-C 的深层面向对象特性。大多数代码都是用来处理对象的，所以默认的返回类型和参数类型是id. 这样做的方便之处在于，编译器并不关心您是否声明了对象的特定类型，只要您在其上使用的方法存在于某处即可。
最大的潜在问题是向它不响应的对象发送消息，因为您不小心认为它是另一种类型的对象。这就是为什么你不应该放弃类型，而是尽可能使用最具体的类型的原因。
我想说第二个约定仅适用于使用语言和运行时的许多动态特性的面向灵活性的代码，而不是您在制作应用程序时大部分时间会遇到的特定对象和类。在适当的地方使用第一个约定可以提高可读性，并且更难出错。这是一个语义问题——尽可能具体地使用你的类型可以排除误解的可能性，并且可以帮助你整体编写更好的代码。
很多 NeXT 时代的代码都遵循了排除(id)返回类型的约定，并且大部分代码都转移到了 OS X 中。当代码排除类型时，我发现它很混乱，现在保存 4-5 个字符是毫无意义的反正。我的猜测是旧习惯很难改掉——我的经验是最佳实践是始终包含返回类型。对于语言的新手来说，它肯定会让事情变得更清楚，并减少假设。