答えて

15

2つは必ずしも入れ替えるとは限りません。概念上、KVOはオブジェクトのプロパティを観察するためだけです。たとえば、オブジェクトのプロパティの変更ではなく、イベントが発生したことをオブザーバに通知するため、KVOを使用してNSApplicationWillTerminateNotificationを置き換えることはできません。

パフォーマンスとメモリの使用に関しては、どちらも高速で、無視できるメモリを使用します。 NSNotificationQueueが合併して、通知の洪水を止めました。私が知る限り、KVOには合体はありません。それは私にとってパフォーマンスの問題を一挙に引き起こしました。私は何百ものオブジェクトを観察していました。バッチ更新がそれらのオブジェクトに起こったとき、私は何百ものKVOコールバックを取得します。 KVO自体のパフォーマンス上の問題ではなく、バッチ更新の結果として自分のコードを実行していました。

パフォーマンスは実際問題ではありません。問題に最も適しています。プロパティ変更の場合は、KVOを使用します。プロパティーの変更でない場合は、単一のオブザーバーまたは複数のオブザーバーが必要かどうかによって、代理人または通知を使用します。

+1

Ah。通知の集約については知らなかった。それは私にとってかなり重要なことです。 – David

+2

通知は、あるオブジェクトが特定の他のオブジェクトについて知る必要がない場合に最もよく使用されます。たとえば、アプリで設定が変更され、通知を使用して設定を管理するオブジェクトの知識がなくても、MVCが維持される場合は、一連のビューを更新することができます。 –

0

非常に古い質問ですが、いくつかの点を追加することを考えました。私はTom Dalling's answerに同意しますが、オブジェクトのプロパティに対してオブザーバを追加する傾向のある大きなアプリケーションには多くのシナリオがあります。オブザーバのリストからオブザーバを削除することはできません。

私のアプリケーションから以下のシナリオを考えてみましょう。ViewControllerはスネークオブジェクトを表示します。このオブジェクトのプロパティ変更を監視しています。ですから、viewControllerが別のヘビを表示する必要があるときは、そのヘビオブジェクトのオブザーバからView Controllerを削除するだけです。

アプリは、単一のヘビの代わりにヘビのリストを表示するように進化しました。つまり、そのオブジェクトのすべてのヘビの特性を観察する必要がありました。さて、古いヘビが配列から削除されると、このイベントについて知るようになり、このヘビオブジェクトからオブザーバとしてビューコントローラを削除できます。これを行うには、配列自体の変更を最初に観察する必要があります。これを行うには、オブジェクトを配列に挿入して配列から削除するために、特定のプロトコルに従わなければなりません。このようにして、複雑さが増します。私たちは皆、オブジェクトからオブザーバを削除しないで、そのオブジェクトがOSによって解放された場合の結果を知っています!

上記は、ここでの主な問題は、このオブジェクトはリリースされる前に、私はオブザーバーからそれらを削除するように指定されたオブジェクトのためのKVOのオブザーバーのリストを取得することはできませんで引用するほんの一例である - これは簡単にNSNotificationとすることにより達成することができますNSNotificationCenter。時には、私はKVO上でNSNotificationを使用する傾向にある傾向がありますが、KVOは常に優れた設計慣行の点で通知に勝っています。