¿El patrón del "centro de notificación" fomenta el diseño bueno o malo del programa?

Navega tus respuestas
13

A veces me encuentro con estas API de tipo hub de mensajes, por ejemplo, Cocoa NSNotificationCenter: enlace

Por lo general, estas API proporcionan un punto de acceso global en el que se suscribe o transmite mensajes / eventos. Creo que esto es un problema porque fomenta una arquitectura de programa plana y no estructurada, donde las dependencias no están explícitas en la API, sino que están ocultas en el código fuente. No está obligado a pensar en la propiedad y jerarquías de los objetos, sino que puede hacer que cualquier objeto en su programa resulte en cualquier código que se llame. Pero tal vez esto es algo bueno?

¿Este patrón generalmente alienta el diseño de programas buenos o malos, y por qué? ¿Hace que el código sea más difícil o más fácil de probar?

Perdóneme si esta pregunta es demasiado vaga o amplia. Estoy tratando de comprender las posibles consecuencias de un uso extensivo de una API como esta y las diferentes formas en que podría usarla.

Editar: supongo que mi mayor problema con este patrón es que la API "miente" sobre las dependencias y los acoplamientos de objetos, y se puede ilustrar con este ejemplo: 

myObj = new Foo();
myOtherObj = new Bar();
print myOtherObj.someValue; // prints 0
myObj.doSomething();
print myOtherObj.someValue; // prints 1, unexpectedly, because I never indicated that these objects had anything to do with each other
    
pregunta Magnus Wolffelt 30.11.2010 - 13:22

4 respuestas

6

No me atrevería a decir que alienta la mala programación. Pero puede ser mal usado fácilmente.

Bueno, ¿cuál es la idea real?
La fuente de la notificación solo hace su notificación. No hace una suposición sobre la existencia de observadores potenciales ni nada. Un observador se registra para las notificaciones que está diseñado para manejar. El observador no hace suposiciones acerca de cuántas fuentes potenciales hay para las notificaciones que puede manejar.

Esta es una forma de lograr la inyección de dependencia, sin que las fuentes conozcan a los observadores o los observadores a las fuentes. Sin embargo, para que todo el sistema funcione, debe conectar a los observadores correctos para las notificaciones correctas, y este sistema es incluso vulnerable a errores tipográficos, ya que no se puede verificar el tiempo de compilación.

El mayor peligro, por supuesto, es que alguien usará esto para hacer que toneladas de objetos estén disponibles globalmente para llamadas al 1-1.

    
respondido por el back2dos 30.11.2010 - 14:01
6

La mensajería asíncrona es un buen principio de arquitectura para sistemas grandes que deben escalarse

El equivalente de Java de esto es JMS y generalmente se considera un algo bueno .

Esto se debe a que promueve el desacoplamiento de su código de cliente del código que realmente sirve para el mensaje. El código del cliente simplemente tiene que saber dónde publicar su mensaje. El código de servicio simplemente tiene que saber dónde recoger los mensajes. El cliente y el servicio no se conocen entre sí y, por lo tanto, pueden cambiar independientemente uno de otro según sea necesario.

Puede externalizar fácilmente el URI del centro de mensajes para que sea configurable y no incrustado en el código fuente.

    
respondido por el Gary Rowe 30.11.2010 - 13:39
4

Esta es una implementación típica de patrón de Oberserver (o algunas veces se llama patrón de escucha o, a veces, patrón de suscriptor / publicador). En aplicaciones donde este comportamiento es útil, es un buen patrón para implementar. No debe implementarse ningún patrón si no agrega valor a la solución.

Por su pregunta, parece que le preocupa que todo sepa sobre el NotificationCenter y que las cosas globales sean MALAS. A veces, sí, las cosas globales son malas. Pero veamos la alternativa. Digamos que tienes 2 componentes, para este ejemplo no importa realmente lo que hacen o lo que son. Componente 1 tiene algunos datos sobre los que se actuó o se modificó de alguna manera. Component2 desea saber sobre cualquier cambio en los datos del tipo que administra Compoent1. ¿Debe saber Component2 sobre la existencia de Component1? ¿O sería mejor que Component2 suscriba / escuche un mensaje que le diga que algún componente en algún lugar de la aplicación cambió algunos datos en los que está interesado? Ahora tome este ejemplo y multiplíquelo por docenas o más componentes y podrá ver dónde se encuentra el valor del patrón.

Es una solución perfecta para cada situación, no. ¿Abstracta la comunicación entre componentes y proporciona un acoplamiento más suelto, sí.

    
respondido por el Walter 30.11.2010 - 13:44
0

Es bueno para los sistemas controlados por eventos, y es más agradable que la alternativa de tener un grupo de observadores observándose unos a otros, ya que es menos probable que termine con bucles infinitos involuntarios de observadores que disparan eventos. Este fue un problema real en los viejos días de VB, cuando tenía controles ActiveX controlados por eventos que podían conectarse entre sí con controladores de eventos.

    
respondido por el TMN 30.11.2010 - 19:30

Lea otras preguntas en las etiquetas

¿Qué debo incluir en los comentarios de la documentación XML? Idea para un currículo y libro de texto conjunto de física e informática [cerrado]