In meiner eigenen Erfahrung:
Delegation:
- PRO: nur verwenden, wenn Sie ein einzelnes Objekt zur Benachrichtigung haben;
- PRO: Mit einem expliziten Protokoll können Sie Ihre Absichten klar dokumentieren;
- CON: kann die Quelle von Abstürzen und Speicherlecks, wenn falsch verwendet (Tipp: Sie Delegierten nicht behalten, weisen Sie sie und erinnern Delegierten deassign wenn/falls sie freigegeben werden)
Ich schrieb über Speicherverwaltung durch Delegation in diesem Artikel auf meinem Blog generiert Probleme:
http://akosma.com/2009/01/28/10-iphone-memory-management-tips/
NSNotification:
- PRO: besser, wenn Sie mehrere Objekte zu benachrichtigen haben;
- PRO: sehr flexibel, führt zu locker gekoppelten Klassen;
- CON: Benachrichtigungen werden synchron gesendet (also stellen Sie sicher, dass Ihre einzelnen Benachrichtigungshandler nur sehr wenig tun)
- CON: manchmal schwer zu dokumentieren und zu pflegen. Stellen Sie sicher, dass Sie in den Kopfdokumenten klar erklären, was jede Benachrichtigung bedeutet und wann sie gesendet wird.
KVO:
- ähnliche Bedenken über NSNotifications;
- CON: noch unklarer zu dokumentieren. Achten Sie darauf, weitere Header-Dokumente oder Architekturtipps zu Ihren Kommentaren hinzuzufügen, um zu erklären, wer was hört. Ich persönlich würde KVO nicht zum Laden oder Analysieren von Daten verwenden. Persönlich
, wenn sie mit netzwerkfähigen Anwendungen im Gespräch mit einem Remote-Web-Service zu tun, verwende ich eine Singleton Data Loader-Klasse (Einwickeln ASIHTTPRequest und Handhabung aller Serialisierung und Deserialisierung), die Meldungen erscheint, wenn etwas geschieht.Auf diese Weise kann der App-Delegierte Verbindungsfehler eigenständig behandeln (z. B. Warnungen anzeigen), und jeder Controller kümmert sich nur um die gewünschten Antworten.
Natürlich hängt dieser Ansatz von der Anwendung ab, aber diese allgemeine Architektur könnte ein Ausgangspunkt für Ihren eigenen Code sein.