为什么 Objective-C 不支持私有方法？

Question

我在Objective-C中看到了许多声明半私有方法的策略，但似乎没有一种方法可以创建真正的私有方法。我接受这一点。但是，为什么会这样呢？我的每一个解释本质上都是在说：“你做不到，但这是一个近似值。”

有许多关键字应用于ivars（成员）来控制其范围，例如@private、@public、@protected。为什么方法不能也这样做呢？这似乎是运行时应该能够支持的。我是否缺少一种潜在的哲学？这是故意的吗？

Answer 1

答案是……嗯……很简单。事实上，简单性和一致性。

Objective-C 在方法分派时是纯粹动态的。特别是，每个方法分派都会经历与其他每个方法分派完全相同的动态方法解析点。在运行时，每个方法实现都具有完全相同的公开，并且 Objective-C 运行时提供的所有与方法和选择器一起使用的 API 在所有方法中都同样有效。

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

将相同的功能复制到运行时没有什么好处。这会增加大量的复杂性和开销。即使具有所有这些复杂性，它仍然不会阻止除了最随意的开发人员之外的所有人执行您所谓的“私有”方法。

编辑：我的假设之一
注意到私人消息会
必须经过运行时
从而产生潜在的大
开销。这绝对是真的吗？

<块引用>

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

私人是没有办法的
短路此检查的方法或
跳过运行时？

<块引用>

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

也就是说，第三方没有理由不能在该对象的实现之外以及某些事物（例如 KVO）故意对该对象调用 objc_msgSendPrivate()必须这样做。实际上，这只是一种约定，在实践中比给私有方法的选择器添加前缀或不在接口标头中提及它们好不了多少。

但这样做会破坏语言的纯粹动态性质。每个方法分派将不再经过相同的分派机制。相反，您将陷入这样一种情况：大多数方法都以一种方式运行，而少数方法只是不同。

这超出了运行时的范围，因为 Cocoa 中有许多机制构建在 Objective-C 的一致动态之上。例如，键值编码和键值观察要么必须进行大量修改才能支持私有方法（很可能是通过创建可利用的漏洞），要么私有方法将不兼容。

Answer 2

运行时可以支持它，但成本将是巨大的。发送的每个选择器都需要检查该类是私有的还是公共的，或者每个类需要管理两个单独的调度表。这与实例变量不同，因为这种级别的保护是在编译时完成的。

此外，运行时需要验证私有消息的发送者与接收者属于同一类。您还可以绕过私有方法；如果该类使用instanceMethodForSelector:，它可以将返回的IMP提供给任何其他类，以便它们直接调用私有方法。

私有方法无法绕过消息调度。考虑以下场景：

1. 类 AllPublic 有一个公共实例方法 doSomething

2. 另一个类 HasPrivate 有一个私有实例方法，也称为 doSomething

3. 您创建一个包含任意数量的 AllPublic 和 HasPrivate 实例的数组

4. 您有以下循环：

   for (id anObject in myArray)
       [一个对象做某事];
   

   如果您从 AllPublic 中运行该循环，则运行时必须阻止您在 HasPrivate 实例上发送 doSomething，但是此循环如果它位于 HasPrivate 类中，则可用。

Answer 3

到目前为止发布的答案很好地从哲学角度回答了这个问题，所以我将提出一个更务实的原因：通过改变语言的语义会得到什么？它足够简单，可以有效地“隐藏”私有方法。举例来说，假设您在头文件中声明了一个类，如下所示：

@interface MyObject : NSObject {}
- (void) doSomething;
@end

如果您需要“私有”方法，您也可以将其放入实现文件中：

@interface MyObject (Private)
- (void) doSomeHelperThing;
@end

@implementation MyObject

- (void) doSomething
{
    // Do some stuff
    [self doSomeHelperThing];
    // Do some other stuff;
}

- (void) doSomeHelperThing
{
    // Do some helper stuff
}

@end

当然，这并不完全 em> 与 C++/Java 私有方法相同，但它实际上足够接近，那么为什么要改变语言的语义以及编译器、运行时等，以添加已经以可接受的方式模拟的功能呢？正如其他答案中所指出的，消息传递语义以及它们对运行时反射的依赖将使处理“私有”消息变得非常重要。

Answer 4

最简单的解决方案就是在 Objective-C 类中声明一些静态 C 函数。根据 static 关键字的 C 规则，它们仅具有文件范围，因此它们只能由该类中的方法使用。

完全不用大惊小怪。

Answer 5

是的，通过利用编译器已经采用的用于处理 C++ 的技术：名称修改，可以在不影响运行时的情况下完成此操作。

它尚未完成，因为尚未确定它可以解决其他技术（例如，前缀或下划线）能够充分规避的编码问题空间中的一些相当大的困难。 IOW，你需要更多的痛苦来克服根深蒂固的习惯。

您可以向 clang 或 gcc 提供补丁，将私有方法添加到语法中，并生成它在编译期间单独识别的损坏名称（并立即忘记）。然后 Objective-C 社区中的其他人将能够确定它是否真的值得。这样可能比试图说服开发人员更快。

Answer 6

本质上，它与 Objective-C 的方法调用的消息传递形式有关。任何消息都可以发送到任何对象，由对象选择如何响应消息。通常，它会通过执行以消息命名的方法进行响应，但它也可以通过许多其他方式进行响应。这并不意味着私有方法完全不可能——Ruby 使用类似的消息传递系统做到了这一点——但它确实让它们有些尴尬。

甚至 Ruby 的私有方法的实现也因为奇怪而让人们感到有点困惑（您可以向对象发送任何您喜欢的消息，除了这个列表中的消息！）。本质上，Ruby 通过禁止使用显式接收者调用私有方法来实现这一点。在 Objective-C 中，这需要更多的工作，因为 Objective-C 没有这个选项。

Answer 7

这是 Objective-C 运行环境的问题。 而 C/C++ 编译成不可读的机器代码, Objective-C 仍然保留了一些人类可读的属性，例如方法名称作为字符串。这使得 Objective-C 能够执行反射功能。

编辑： 作为一种没有严格私有方法的反射语言，Objective-C 更加“Pythonic”，因为您信任其他使用您代码的人，而不是限制他们可以调用哪些方法。使用双下划线等命名约定的目的是向临时客户端编码人员隐藏您的代码，但不会阻止编码人员需要做更认真的工作。

Answer 8

根据问题的解释，有两个答案。

第一种方法是从接口中隐藏方法实现。这通常与没有名称的类别一起使用（例如@interface Foo()）。这允许对象发送这些消息，但不能发送其他消息 - 尽管仍然可能会意外（或以其他方式）覆盖。

第二个答案，假设这与性能和内联有关，是可能的，但作为本地 C 函数。如果您想要一个“private foo(NSString *arg)”方法，您可以执行 void MyClass_foo(MyClass *self, NSString *arg) 并将其作为 C 函数调用就像MyClass_foo(self,arg)。语法有所不同，但它具有与 C++ 私有方法相同的性能特征。

虽然这回答了问题，但我应该指出，无名类别是迄今为止更常见的 Objective-C 方法。

Answer 9

Objective-C 不支持私有方法，因为它不需要它们。

在 C++ 中，每个方法在类的声明中都必须可见。您不能拥有包括头文件在内的其他人看不到的方法。因此，如果您想要实现之外的代码不应该使用的方法，您别无选择，编译器必须为您提供一些工具，以便您可以告诉它不能使用该方法，即“private”关键字。

在 Objective-C 中，您可以拥有头文件中没有的方法。因此，通过不将该方法添加到头文件中，您可以很容易地实现相同的目的。不需要私有方法。 Objective-C 还有一个优点，即您不需要因为更改私有方法而重新编译类的每个用户。

对于实例变量，您过去必须在头文件中声明（不再是了），可以使用 @private、@public 和 @protected。

Answer 10

这里缺少的答案是：因为从可进化性的角度来看，私有方法是一个坏主意。在编写方法时将其设为私有似乎是个好主意，但它是早期绑定的一种形式。上下文可能会发生变化，并且以后的用户可能想要使用不同的实现。有点挑衅：“敏捷开发人员不使用私有方法”

在某种程度上，就像 Smalltalk 一样，Objective-C 适合成年程序员。我们重视了解原始开发人员假设的接口应该是什么，并在需要更改实现时承担处理后果的责任。所以是的，这是哲学，而不是实施。