cocoa - 为什么 Cocoa 绑定(bind)同时使用 KVC 和 KVO 而不仅仅是 KVC？

Question

作为 Cocoa 和 Objective-C 的新手，我对 KVC 和 KVO 有初步的了解。然而，关于 Cocoa 绑定(bind)(如标题为“Cocoa 绑定(bind)编程主题”的 Apple 文档中所述，请参阅图 8-10)，我不清楚为什么他们描述使用 KVC 和 KVO，而看起来 KVO 就足够了。 KVO 的 ObserveValueForKeyPath:ofObject:change:context 可以提供旧值和新值，那么为什么需要 KVC 机制呢？注意，我看到了 KVO 如何解耦对象，但 KVC 也是如此。

Apple 给出的示例(图 8-10)描述了一个窗口，其中包含一个 slider 和一个文本输入控件(用于直观地表示并允许用户交互设置和查看“温度”)、一个 Controller 对象以及一个具有温度属性的模型对象。因此，换句话说，我的问题是为什么不在两个控件和 Controller 之间建立双向 KVO 关系(每个控件都作为观察者注册到另一个)，以及在模型对象和 Controller 之间建立双向 KVO 关系？为什么需要KVC？

Answer 1

冗长的文档让您感到困惑。

这一切都是为了代码可重用性。

(1) 提供声明和管理属性的标准方法。(您可以使用 ivars、setter 和 getter 以旧方式手动完成此操作，但属性合成免费为您提供)

除非键值对遵循约定，否则您无法可靠地观察它们。惯例是KVC。接下来是 KVC 合规性。

(2) 为对象提供一种高度可重用且通用的方式来接收有关另一个对象中的属性更改的通知。这就是 KVO。KVO 能够根据首先符合 KVC 的属性更改对通知进行通用编码。

(3) 绑定(bind)和核心数据。这两种技术都基于 KVC 和 KVO 构建，以使这一切以尽可能通用的方式工作。

它在概念上也与 Active Record 和 Ruby on Rails 等 ORM 非常相似。魔法从 KVC 开始。KVC 实现了简单的 KVO 机制。KVO + KVC 使绑定(bind)和核心数据变得可能且简单。它们还提供了大量的语法糖和古怪的便利。您可以将 KVC 兼容对象的接口(interface)视为字典或数组。然后所有的模式都会就位。

您还可以拥有其他双向观察者模式。委托(delegate)(将彼此设置为或共享委托(delegate))和通知(通过 NSNotification)，甚至只是简单地向其他对象发送消息(如果这是您的模式，则可能是紧密耦合，导致创建这些其他模式)这些并没有错，但需要一些权衡。

通知有时可能是意大利面条式代码。与所有回调一样，有时您最终会得到类似 goto 的结果。然而，它不一定与 KVO 等特定对象的特定属性紧密耦合。它只是在等待一个可能非常笼统的通知，其中可能包含很多不同的内容。然而，就其本质而言，通知往往更具体于用例，并且易于应用于自定义场景。

KVO 作为一种特定技术是基于 KVC 约定构建的，没有它们就无法工作。它使一些非常基本、常见的样板代码和紧密耦合更容易创建。