Delegados vs. events en Cocoa Touch

Estoy escribiendo mi primera aplicación de iPhone, y he estado explorando los patrones de layout en Cocoa Touch y Objective-C. Vengo de un context de desarrollo web del lado del cliente, por lo que trato de concentrarme en los delegates.

Específicamente, no veo por qué se necesitan objects de delegado en lugar de controlleres de events. Por ejemplo, cuando el usuario presiona un button, se maneja con un evento ( UITouchUpInside ), pero cuando el usuario termina de ingresar a un textbox y lo cierra con el button 'Listo', la acción se maneja llamando a un método en el delegado del textbox ( textFieldShouldReturn ).

¿Por qué usar un método de delegado en lugar de un evento? También noto esto en el controller de vista con el método viewDidLoad . ¿Por qué no solo usas events?

EDIT: Otra buena publicación: NSNotificationCenter vs delegación (usando protocolos)?

Un delegado es una callback, por lo que hay una relación 1: 1. El delegado es una sola instancia de un object que implementa un protocolo formal.

Las notifications (events) son básicamente transmisiones a muchos objects que están interesados ​​cuando ocurre algo.

Los delegates son buenos para poder intercalar código en la canalización de otros processs de objects, como antes y después de las devoluciones de llamada, proporcionando fonts de datos para un control y la comunicación entre las vistas:

¿Qué hace exactamente el delegado en el proyecto xcode ios?

Por lo tanto, los delegates tienen una relación mucho más estrecha con el object, ya que son el único object provisto para interponer y modificar el procesamiento del object o proporcionar datos. Está aplazando las decisiones y las operaciones externas, como cargar datos a otro object, por lo que es un patrón muy común para las classs genéricas de UIKit. Las notifications a otros objects son una relación mucho más flexible: es que notifica a los demás que algo sucedió.

Tampoco es una pregunta "vs" necesariamente. Por ejemplo, podría tener una aplicación que realiza el procesamiento en segundo plano y que haya disparado una notificación modificada que provoca que una vista llame a su delegado de origen de datos para actualizar su vista. Son dos mecanismos diferentes.

Los events y delegates tienen dos propósitos diferentes, por lo que verá los dos utilizados.

Si solo desea que su button presione para disparar un post, un evento está bien. Si desea que el button Listo presione para validar el context del campo de text antes de que se le permita perder el foco, puede usar el método delegado textFieldShouldReturn para manejar cualquier validation y devolver NO si no se valida.

Los delegates realmente le permiten cambiar el comportamiento sin subclasss. Están llenos de methods de deber y hacer para este propósito. Usted implementa estos methods en lugar de anular los methods de acción cuando quiere validar, notificar o procesar antes y / o después de la acción.

Si se encuentra pensando que necesita subclasificar un object UIKit, primero verifique los methods de delegado. Es probable que ya haya un lugar para poner tu comportamiento personalizado.

Una distinción clara es que los methods delegates pueden tener valores de retorno ya que existe una relación de uno a uno. Por otro lado, los events están vagamente acoplados a la class de envío, que generalmente no le importa si algo responde o no.

Otros methods delegates están simplemente allí por conveniencia y pueden tener events correspondientes que también se activan.