使用“id”输入方法
在 Objective-C 中，我通常看到返回动态类型对象的方法，定义如下：
- (id)someMethod:(id)someParameter;
我知道我也可以这样做：
- someMethod:someParameter;
有趣的是，我在更多核心级基础类中看到后一种约定，但其他人好像用的是第一个。既然 Objective-C 运行时推断无类型方法或参数将返回 id，为什么我应该包含它？不会破坏阅读的流畅性吗？
我不仅想知道开发人员是否考虑使用此约定可能出现的问题，还想知道你们是否认为这很奇怪？
In Objective-C, I usually see methods that return a dynamically typed object defined as follows:
- (id)someMethod:(id)someParameter;
I know that I can do this, though, as well:
- someMethod:someParameter;
Interestingly, I see the latter convention in more core-level foundation classes, but everyone else seems to use the first. Since the Objective-C runtime infers that an untyped method or parameter will return id, why should I include it? Doesn't it break the flow of reading?
I would like not only to know that devs think about possible problems with using this convention, but also whether you guys think it is just plain weird?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于该语言允许这两种形式，因此这实际上是风格问题。鉴于此，Objective-C 严重依赖于可读性而不是简洁性，大多数开发人员更喜欢第一个 (
-(id)someMethod)，因为它明确了返回类型。与您的问题不直接相关，但
id不是动态类型的。它是一个指向 Objective-C 对象的指针。由于消息调度在 Objective-C 中是动态的，因此id通常可以被视为动态类型，但它实际上仍然是静态类型。换句话说，Objective-C 是动态绑定的，但是是静态类型的。Since the language permits both forms, it's really a mater of style. Given that, Objective-C leans heavily on readability over terseness, and most devs would prefer the first (
-(id)someMethod) becuase it makes explicit the return type.Not directly relevant to your question, but
idis not dynamically typed. It is a pointer to an Objective-C object. Since message dispatch is dynamic in Objective-C,idcan often be treated like a dynamic type, but it's still actually a static type. In other words, Objective-C is dynamically bound but statically typed.首先，我相信是编译器推断类型，而不是运行时。
我相信第二个约定来自于 Objective-C 的深层面向对象特性。大多数代码旨在处理对象，因此默认返回类型和参数类型是
id。这样做的便利之处在于，编译器并不关心您是否声明对象的特定类型，只要您使用的方法存在于某处即可。最大的潜在问题是将消息发送到它不响应的对象，因为您不小心认为它是另一种类型的对象。这就是为什么您不应该放弃类型，而应该使用最具体的类型的原因。
我想说，第二个约定仅适用于使用语言和运行时的大量动态功能实现灵活性的代码，而不是您在创建应用程序时大多数时间会遇到的特定对象和类。在适当的情况下使用第一个约定可以提高可读性并减少犯错误的可能性。这是一个语义问题 - 尽可能具体地说明您的类型，消除了误解的可能性，并且可以帮助您编写更好的整体代码。
First, I believe it's the compiler that infers the type, not the runtime.
I believe the second convention comes from the deep-set object-oriented-ness of Objective-C. Most code is meant to be dealing with objects, and so the default return type and argument type is
id. The convenience of this is that the compiler doesn't care if you declare the specific type of an object, as long as the methods you use on it exist somewhere.The biggest potential problem would be sending messages to an object that it doesn't respond to, because you accidentally thought it was another type of object. This is a reason why you shouldn't leave off types, but instead use the most specific one possible.
I would say the second convention is only a good idea for code that's oriented towards flexibility using lots of dynamic features of the language and runtime, not the specific objects and classes that you'll run into most of the time when making applications. Using the first convention where appropriate improves readability and makes it harder to make mistakes. It's an issue of semantics — being as specific as possible with your types leaves out the possibility of misinterpretation and can help you write better code overall.
许多 NeXT 时代的代码都遵循这种排除返回类型
(id)的约定，并且大部分代码都被带入了 OS X。当代码排除类型时，我发现它很混乱，无论如何，现在节省 4-5 个字符是毫无意义的。我的猜测是，旧习惯很难改掉——我的经验是，最佳实践是始终包含返回类型。对于该语言的新手来说，这无疑让事情变得更加清晰，并且做出了更少的假设。A lot of NeXT-era code followed this convention of excluding the
(id)for the return type, and most of that code carried over into OS X. I find it confusing when the code excludes the type, and saving 4-5 characters is pretty pointless nowadays anyway. My guess is that old habits die hard — my experience is that best practice is to always include the return type. It certainly makes things clearer for newcomers to the language and makes fewer assumptions.