为什么Cocoa绑定同时使用KVC和KVO，而不是只使用KVC？

Question

作为Cocoa和Objective-C的新手，我对KVC和KVO有一个基本的了解。然而，关于Cocoa绑定(如标题为"Cocoa Bindings Programming Topics“的Apple文档中所述，请参阅图8-10)，我不清楚为什么它们同时使用KVC和KVO进行描述，而KVO似乎就足够了。KVO的ObserveValueForKeyPath:ofObject:change:context可以提供旧值和新值，那么为什么需要KVC机制呢？请注意，我看到了KVO如何解耦对象，但KVC也是如此。

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

Answer 1

冗长的文档把你搞糊涂了。

所有这些都是关于代码的可重用性。

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

您无法可靠地观察键值对，除非它们遵循约定。约定是KVC。紧随其后的是KVC兼容。

(2)为对象提供了一种高度可重用和通用的方式，用于接收另一个对象中某个属性更改的通知。这里是KVO。KVO是一种基于属性更改对通知进行通用编码的能力，这些属性首先符合KVC。

(3)绑定和核心数据。这两种技术都建立在KVC和KVO之上，以尽可能通用的方式工作。

它在概念上也与活动记录和Ruby on Rails等ORM非常相似。魔力始于KVC。KVC实现了一种简单的KVO机制。KVO + KVC使得绑定和核心数据变得可能和简单。它们还提供了许多语法糖和古怪的便利。您可以将与KVC兼容的对象的接口视为字典或数组。然后，所有的模式都到位了。

你仍然可以有其他的双向观察者模式。委托(将彼此设置为或共享一个委托)和通知(通过NSNotification)，甚至是简单地传递其他对象(如果这是到处都是你的模式，可能会导致不好的紧密耦合，导致创建其他模式)这些都不是错误的，但有一些权衡。

通知有时可能是意大利面条代码。像所有的回调一样，有时你会得到类似goto的结果。但是，它不一定与KVO等特定对象的特定属性紧密耦合。它只是在等待一个潜在的非常通用的通知，它可能包含许多不同的东西。然而，从本质上讲，通知更倾向于特定于用例，并且易于应用于自定义场景。

KVO作为一种特定技术是建立在KVC约定之上的，没有它们就不能工作。它使得一些非常基本的、通用的样板代码和紧耦合更容易创建。

Answer 2

一些人已经在评论中尝试过了，他是我的go：

KVO本质上构建在KVC之上-当符合KVC的属性发生变化时，如果有观察者，那么KVO机制就会介入，根据需要构建信息字典，并将消息发送给观察者。

如果他们问的是为什么这样做，为什么不是另一种方式，那就是另一个问题了。KVO需要插入一些东西--您不能仅仅以简单的方式观察变量(内存位置)的变化。拥有setter和getter的属性是KVO之类的东西可以挂接的地方。并且属性遵循KVC模式，并且已经有了支持该模式的机制...但这并不意味着KVO必须依赖于KVC，其他实现策略无疑也是可能的。

HTH一点都没有。

*在这种情况下，进入调试模式并部署观察点并不“简单”！