关键价值观察 - 寻找更优雅的解决方案来应对价值变化

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适应基于块的回调是火箭科学。您链接到的基于方法的方法似乎不是简单的向前迈出的一步。我知道你正在尝试采用基于字符串的密钥路径的不确定性＆lt; - ＆gt;方法转换出方程式，但是这种方式会下降，因为并非所有可观察的键/ keyPath都是方法。 （如果没有别的，你可以在NSMutableDictionaries上观察任意键并获得通知。）

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