1つのオブジェクトのみと通信する場合は、デリゲートを使用します。たとえば、tableViewにはデリゲートがあります。1つのオブジェクトのみがそれを処理する必要があります。
何かが起こったことを全員に伝えたい場合は、通知を使用します。たとえば、メモリ不足の状況では、メモリ警告が発生したことをアプリに通知する通知が送信されます。アプリ内の多くのオブジェクトがメモリ使用量を減らしたい場合があるため、それは通知です。
KVOは良い考えではないので使用しないようにしますが、プロパティが変更されたかどうかを確認したい場合は、変更をリッスンできます。
お役に立てば幸いです。
「マスター/スレーブ」関係（デリゲートがクラスを知っており、クラスがデリゲートを知っている）で、コントロール階層の上位に1つのクラスがあり、他の状況が発生しないことが明らかな場合は、デリゲートを使用します。要素（主にUI）は、クラスが何を言っているかを知ることに関心があります。
通知を使用するのは、クラスが誰が聞いているか、何人聞いているかを知りたくない場合、誰でも、どんな数でも通知に登録できます。
KVOは「クラスを知らないで」聞くのに役立ちますが、もちろんそうではありませんが、KVOが適用されるクラスを変更する必要はありません。
3つの状況すべてが状況に応じて役立つ場合でも、デリゲートは優先オプションです。
- 再利用性。
- 自己文書化。クラスのヘッダーファイルを調べることにより、データ交換の内容/方法がすぐにわかります。
委任は、他のオブジェクトで送信者の動作を変更するときに使用する設計パターンです。例：ターミナルウィンドウのデリゲートがこれを保証するためにウィンドウのサイズを変更するため、ターミナルウィンドウでは、ウィンドウの端で切り取られた線や文字が表示されなくなります。
通知は、応答が必要ないときに使用するパターンです。例：システムがまもなくスリープ状態になるという通知を受け取ります。その通知の送信者は、あなたがそれについて何をするかを気にしません。
私の意見では、オーバーヘッドがゼロの利点があるため、KVOの方が優れています。通知を使用/監視していない場合でも、通知にはオーバーヘッドがあります。改善するには、さまざまなNotificationCenterを使用できますが、それでも多少のオーバーヘッドが発生します（間違っている場合は修正してください）。 KVOは少し複雑ですが、多くのものを観察する必要がある場合には価値があります。