在 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个字符是毫无意义的。我的猜测是旧习惯很难改掉——我的经验是，最佳实践是始终包含返回类型。对于语言的新手来说，这肯定会让事情变得更清楚，并且做的假设更少。
【讨论】：