我遇到了 KVO 的一个令人沮丧的功能:所有通知都通过单个方法 (observeValueForKeyPath:....
) 汇集,如果对象正在观察大量的情况,则需要一堆 IF 语句属性。
理想的解决方案是将一个方法作为参数传递给首先建立观察的方法,但似乎这是不可能的。这个问题有解决办法吗?我最初考虑使用 keyPath 参数 (addObserver:forKeyPath:options:context:) 通过 NSSelectorFromString 调用方法,但后来我遇到了帖子 KVO Dispatcher pattern with Method as context 及其链接的文章提供了不同的解决方案,以便也传递参数(尽管我还没有实现该功能)。
我知道很多人都遇到过这个问题。有处理它的标准方法吗?
最佳答案
OP 询问:
Has a standard way of handling it emerged?
不,不是真的。有很多不同的方法。以下是一些:
- 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 使用基于 block 的回调是火箭科学。为了简单起见,您链接到的基于方法的方法似乎并不是向前迈出的一步。我知道您试图将基于字符串的键路径 <-> 方法转换的不确定性从等式中剔除,但这种情况会失败,因为并非所有可观察的键/keyPath 都是方法。 (如果不出意外,您可以观察 NSMutableDictionaries 上的任意键并获取通知。)
如果 Apple 能够发布新的基于 block 的 KVO API,那肯定会很好,但我并没有屏住呼吸。但与此同时,就像我说的,只需选择一个您喜欢的并使用它,或者编写您自己的并使用它。
关于iphone - Key-Value-Observation——寻找更优雅的解决方案来响应值的变化,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9474049/