ここでの経験則は、イベントの通知を希望するクライアントの数です。それが主に1つのオブジェクトである場合（たとえば、ビューを閉じるか、クリックされたボタンを操作するため、またはダウンロードの失敗に対応するため）、デリゲートモデルを使用する必要があります。
発生したイベントが一度に多くのオブジェクトに関係する可能性がある場合（画面の回転、メモリ使用量、ユーザーのログイン/ログアウトなど）は、NSNotificationCenterを使用する必要があります。
それらの目的は異なります：
通知は、送信者から知られていない可能性のある複数の受信者にメッセージをブロードキャストするために使用されます。
委任は、送信者に代わって機能する既知の単一の受信者にメッセージを送信するために使用されます。
通知は一般に、他のスレッドで発生した変更をUIに通知する場合にも適しています。 Appleのドキュメントでは、安定性とパフォーマンスの両方の理由から、可能な限りスレッド間でデリゲートを使用しないことを強くお勧めしています。 Macでは、Bindingsの使用を推奨していますが、iPhoneには存在しないため、おそらく通知が次善策です。
パフォーマンスを考慮することは良いアイデアです（少数の通知されたオブジェクトには委任がよく、多数のオブジェクトには通知センターが適していますか、それともプロファイラーを実行します）。ただし、Objective-CとCで記述されている可能性が高い、コードベースの非常に高性能な部分について話している可能性が低いため、モジュール間のコンパイル時の依存関係が減少しています。
単一のデリゲートではなく、デリゲートの配列を持つことを妨げるものは何もありません。
NSNotificationCenterは、作成したネットワークスタックコンポーネントとカスタムデバイスステータス監視インターフェイスのステータスにのみ使用する場合があります。しかし、ほとんどのカップリングでは、アプリのグローバルステータスとは関係なく、ほとんどの場合、Objective-Cで通常のインターフェイスコントラクトを使用する方が明確で、NSNotificationCenterを使用するよりも、後から来る人々を追跡する方が簡単だと思います。実際、私は自分のカスタムイベントにNotificationCenterを使用したことがなく、他の誰かが私のコードを読んで理解しやすいようにデリゲートを使用することを好みます。
そして最後に、もちろん、標準APIとの間の通知では、選択の余地はなく、2つのメソッドのいずれかを使用する必要がありますApple特定のイベントを禁止します。
通知は、UIコンポーネントの分離に適しています。コントローラーやモデルを変更せずに、任意のビューを接続できます。疎結合設計には間違いなく優れています。
ただし、委任と通知の間のパフォーマンスについては、呼び出しの頻度を考慮する必要があります。
委任は、より頻繁なイベントに適しています。通知は、頻度が少ないが受信者が多い場合に適しています。何を選ぶかはプロジェクト次第です。
これら2つの間のオプションは、NSNotificationCenterなしのオブザーバーパターンを使用することです。私のObjective-C実装 here を見てください。