Key-Value-Observation——寻找更优雅的解决方案来响应价值变化

Question

我遇到了一个令人沮丧的 KVO 特性：所有通知都通过一个方法 (observeValueForKeyPath:....) 汇集，如果对象正在观察许多属性，则需要一堆 IF 语句。

理想的解决方案是将方法作为参数传递给首先建立观察的方法，但这似乎是不可能的。这个问题是否存在解决方案？我最初考虑使用keyPath 参数（addObserver:forKeyPath:options:context:）通过NSSelectorFromString 调用方法，但后来我遇到了KVO Dispatcher pattern with Method as context 的帖子和它链接的文章，它提供了不同的解决方案以便传递参数以及（虽然我还没有得到那个工作）。

我知道很多人都遇到过这个问题。是否出现了处理它的标准方法？

Answer 1

OP 询问：

出现了处理它的标准方法吗？

不，不是真的。有很多不同的方法。以下是一些：

• https://github.com/sleroux/KVO-Blocks
• http://pandamonia.github.io/BlocksKit
• http://www.mikeash.com/pyblog/friday-qa-2012-03-02-key-value-observing-done-right-take-2.html
• https://github.com/ReactiveCocoa/ReactiveCocoa
• http://blog.andymatuschak.org/post/156229939/kvo-blocks-block-callbacks-for-cocoa-observers
• 说真的，有很多这样的...Google "KVO blocks"

我不能说我所看到的任何选项似乎都足以赢得“标准方式”的称号。我怀疑大多数有动力去克服这个问题的人只是选择一个并继续使用它，或者自己编写——这并不是说让 KVO 使用基于块的回调是火箭科学。为简单起见，您链接到的基于方法的方法似乎不是向前迈出的一步。我知道您正在尝试将基于字符串的键路径 方法转换的不确定性排除在等式之外，但是这种情况会下降，因为并非所有可观察的键/键路径都是方法。 （如果不出意外，您可以观察 NSMutableDictionaries 上的任意键并获取通知。）

如果 Apple 发布新的基于块的 KVO API 肯定会很好，但我并没有屏住呼吸。但与此同时，就像我说的那样，只需选择一个你喜欢的并使用它，或者自己编写并使用它。