objective c - guidelines - Singleton con un delegado: ¿Buena idea o mala?
ios design guidelines (4)
He creado objetos que son interfaces para un servicio web. Un objeto típico sería un "TaskService". Cuando un cliente utiliza uno de estos objetos, invoca uno de los métodos del servicio (como "GetTasks") y el servicio se activa de forma asíncrona para llamar al servicio web remoto y publicar los datos recuperados a través de un delegado.
Actualmente, para usar uno de estos servicios, debe crearlo con [[TaskService alloc] init], pero decidí que tiene más sentido convertir cada servicio en un objeto singleton.
¿Es común ver objetos únicos que hacen referencia a los delegados? Mi principal problema con el diseño, es que cada objeto, siempre que requiera el uso de un servicio en particular, tendrá que establecerse como el delegado antes de invocar el servicio, lo que no me parece del todo correcto ... ¿Qué pasa si otro objeto ¿Debería establecerse como el delegado entre usted y usted como delegado e invocando el servicio?
¡Muchas gracias de antemano!
Saludos, Nick
El alcance de un singleton es la aplicación completa. Por ejemplo: Consideremos el ejemplo de la aplicación de compras, los datos del registrador, el ID del usuario que debe ser accesible en diferentes partes de la aplicación, como el pedido, el pago, el carrito, etc.
Los delegados se utilizan para la comunicación 1 a 1, por ejemplo: Puede tomar como ejemplo Tiene dos clases de TV y dispositivo de control remoto. Quieres cambiar el canal de TV. Los métodos delegados de TV para cambiar el canal se implementan en la clase de dispositivo de control remoto. Entonces usa el dispositivo de control remoto y cambia el canal del televisor.
El singleton se usa para comunicarse con múltiples receptores, mientras que el patrón de delegación se usa generalmente para comunicación de 1 a 1.
Imo, esta no es una buena idea por el motivo que citó. El patrón de Singleton es realmente para cosas de las que solo hay una, pero parece que su aplicación puede necesitar varias instancias de estos servicios. Creo que terminará trabajando en esto (utilizando una cola de operaciones o algún tipo de multiplexor de delegados) cuando realmente solo necesite crear instancias de varias instancias de su servicio.
Singleton no es realmente el problema, usted causa el mismo tipo de problemas simplemente instalando una clase y pasándola como una variable global. Como otros han mencionado una cola es una posibilidad, o cuando invocas una tarea en un servicio en tu Singleton tienes como ejemplo un objeto TaskRequest que pasa en el método y el delegado de devolución de llamada, de esa manera las solicitudes no pueden pisotearse entre sí. De hecho, sería una buena idea hacer eso con una cola de todos modos.
Cuando la ocasión justifique el uso de un objeto Singleton, siempre evito la delegación por el motivo que citan. Los consumidores de un singleton no pueden saber (sin una codificación fea) si están pisando los dedos de los otros consumidores al establecerse como el único delegado del singleton. NSNotifications es una herramienta mucho más limpia para el trabajo; cualquier cantidad arbitraria de oyentes puede consumir las notificaciones sin importar quién más puede estar escuchando.
La delegación funciona mejor cuando hay una propiedad clara entre las clases. Nadie posee un singleton.