为什么Objective-C不支持私有方法? [英] Why doesn't Objective-C support private methods?

问题描述

我已经看到了许多在 Objective-C 中声明半私有方法的策略，但是似乎没有一种方法可以实现真正的私有方法.我接受.但是，为什么会这样呢?我基本上说过的每一种解释都是:你做不到，但这是一个近似值."

I've seen a number of strategies for declaring semi-private methods in Objective-C, but there does not seem to be a way to make a truly private method. I accept that. But, why is this so? Every explanation I've essentially says, "you can't do it, but here's a close approximation."

ivars(成员)有许多关键字可以控制其范围，例如@private，@public，@protected.为什么不能同时为方法完成此操作?似乎运行时应该能够支持.我是否缺少基本的哲学?这是故意的吗?

There are a number of keywords applied to ivars (members) that control their scope, e.g. @private, @public, @protected. Why can't this be done for methods as well? It seems like something the runtime should be able to support. Is there an underlying philosophy I'm missing? Is this deliberate?

推荐答案

答案很简单.实际上，简单性和一致性.

The answer is... well... simple. Simplicity and consistency, in fact.

Objective-C在方法分派时是纯动态的.特别是，每个方法分派都经过与其他所有方法分派完全相同的动态方法解析点.在运行时，每种方法实现都具有完全相同的公开范围，并且由Objective-C运行时提供的，与方法一起使用的所有API和选择器在所有方法上均具有相同的作用.

Objective-C is purely dynamic at the moment of method dispatch. In particular, every method dispatch goes through the exact same dynamic method resolution point as every other method dispatch. At runtime, every method implementation has the exact same exposure and all of the APIs provided by the Objective-C runtime that work with methods and selectors work equally the same across all methods.

许多人回答了(在这里和其他问题中)，都支持编译时私有方法.如果一个类没有在其公共可用接口中声明一个方法，那么就您的代码而言，该方法也可能不存在.换句话说，通过适当地组织项目，可以在编译时实现所需的可见性的所有各种组合.

As many have answered (both here and in other questions), compile-time private methods are supported; if a class doesn't declare a method in its publicly available interface, then that method might as well not exist as far as your code is concerned. In other words, you can achieve all of the various combinations of visibility desired at compilation time by organizing your project appropriately.

将相同功能复制到运行时几乎没有好处.这将增加大量的复杂性和开销.即使存在所有这些复杂性，它也不会阻止除最随意的开发人员以外的所有人员执行您所谓的私有"方法.

There is little benefit to duplicating the same functionality into the runtime. It would add a tremendous amount of complexity and overhead. And even with all of that complexity, it still wouldn't prevent all but the most casual developer from executing your supposedly "private" methods.

我的假设之一 注意到私人消息会 必须通过运行时 导致潜在的大 高架.这是真的吗?

One of the assumptions I've noticed is that private messages would have to go through the runtime resulting in a potentially large overhead. Is this absolutely true?

是的.没有理由假设类的实现者不想使用实现中的所有Objective-C功能集，这意味着必须进行动态分配. 但是，没有特殊原因为什么不能通过objc_msgSend()的特殊变体来调度私有方法，因为编译器会知道它们是私有的.即可以通过在Class结构中添加专用方法表来实现.

Yes, it is. There's no reason to suppose that the implementor of a class would not want to use all of the Objective-C feature set in the implementation, and that means that dynamic dispatch must happen. However, there is no particular reason why private methods couldn't be dispatched by a special variant of objc_msgSend(), since the compiler would know that they were private; i.e. this could be achieved by adding a private-only method table to the Class structure.

没有私人的方式 将该检查短路的方法或 跳过运行时?

There would be no way for a private method to short-circuit this check or skip the runtime?

它不能跳过运行时，但是运行时不一定必须对私有方法进行任何检查.

It couldn't skip the runtime, but the runtime wouldn't necessarily have to do any checking for private methods.

也就是说，没有理由第三方无法在该对象的实现之外故意在该对象上调用objc_msgSendPrivate()，并且某些事情(例如，KVO)必须这样做.实际上，这只是惯例，实际上比在私有方法的选择器前添加前缀或在接口头中不提及它们要好.

That said, there's no reason that a third-party couldn't deliberately call objc_msgSendPrivate() on an object, outside of the implementation of that object, and some things (KVO, for example) would have to do that. In effect, it would just be a convention and little better in practice than prefixing private methods’ selectors or not mentioning them in the interface header.

但是，这样做会破坏语言的纯粹动态特性.不再将每个方法的调度都通过相同的调度机制进行.取而代之的是，您将处于大多数方法只能以一种方式工作而少数方法却有所不同的情况下.

To do so, though, would undermine the pure dynamic nature of the language. No longer would every method dispatch go through an identical dispatch mechanism. Instead, you would be left in a situation where most methods behave one way and a small handful are just different.

这超出了运行时的范围，因为Cocoa中有许多机制是建立在Objective-C始终如一的动力之上的.例如，密钥值编码和密钥值观察要么必须进行大量修改以支持私有方法(最有可能通过创建可利用的漏洞)，否则私有方法将不兼容.

This extends beyond the runtime as there are many mechanisms in Cocoa built on top of the consistent dynamism of Objective-C. For example, both Key Value Coding and Key Value Observation would either have to be very heavily modified to support private methods — most likely by creating an exploitable loophole — or private methods would be incompatible.

这篇关于为什么Objective-C不支持私有方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！