En mi propia experiencia:
Delegación:
- PRO: utilícelo solo cuando tenga un solo objeto para notificar;
- PRO: utilizando un protocolo explícito, puede documentar claramente sus intenciones;
- CON: puede ser el origen de los accidentes y pérdidas de memoria si se utiliza erróneamente (consejo: no conservan los delegados, asignarlos, y recordar a los delegados desasignar cuando/si son liberados)
escribí acerca de los problemas de gestión de memoria generadas por delegación en este artículo en mi blog:
http://akosma.com/2009/01/28/10-iphone-memory-management-tips/
NSNotification:
- PRO: mejor cuando tiene varios objetos para notificar;
- PRO: muy flexible, conduce a clases débilmente acopladas;
- CON: las notificaciones se envían de forma síncrona (así que asegúrese de que sus manejadores de notificación individuales solo hagan muy poco)
- CON: a veces es difícil de documentar y mantener. Asegúrese de explicar claramente en los documentos del encabezado qué significa cada notificación y cuándo se envía.
KVO:
- preocupaciones similares sobre NSNotifications;
- CON: aún más oscuro para documentar. Asegúrese de agregar más documentos de encabezado o consejos arquitectónicos sobre sus comentarios para explicar quién está escuchando qué. Personalmente, no utilizaría KVO para cargar datos o tareas de análisis.
Personalmente, cuando se trata de aplicaciones de red habilitados para hablar con un servicio web remoto, utilizo una clase cargador de datos Singleton (envolviendo ASIHTTPRequest y gastos de toda la serialización y deserialización) que aparece notificaciones cuando ocurre algo.De esta forma puedo hacer que el delegado de la aplicación maneje los errores de conexión por sí mismo (apareciendo alertas y, si es necesario) y cada controlador solo se preocupa por las respuestas que quiere.
Por supuesto, este enfoque depende de la aplicación, pero esta arquitectura general podría ser un punto de partida para su propio código.