Nombre del patrón: ObserverDescripción: Separa el despliegue del estado de un objeto del objeto en sí y permite el ofrecimiento de despliegues alternativos. Cuando cambia el estado del objeto, todos los despliegues se notifican automáticamente y se actualizan para reflejar el cambio.Descripción del problema: En muchas situaciones hay que proporcionar múltiples despliegues de información del estado, tales como un despliegue gráfico y un despliegue tabular. Tal vez no se conozcan todos éstos cuando se especifica la información. Todas las presentaciones alternativas deben soportar la interacción y, cuando cambia el estado, los despliegues en su totalidad deben actualizarse.Este patrón puede usarse en todas las situaciones en que se requiera más de un formato de despliegue para información del estado y donde no es necesario que el objeto mantenga la información del estado para conocer sobre los formatos específicos de despliegue utilizados.Descripción de la solución: Esto implica dos objetos abstractos, Subject y Observer, y dos objetos concretos, ConcreteSubject (sujeto concreto) y ConcreteObject (objeto concreto), que heredan los atributos de los objetos abstractos relacionados. Los objetos abstractos contienen operaciones generales que son aplicables en todas las situaciones. El estado a desplegar se mantiene en ConcreteSubject, que hereda operaciones de Subject y le permite agregar y remover Observers (cada observador corresponde a un despliegue) y emite una notificación cuando cambia el estado. ConcreteObserver (observador concreto) mantiene una copia del estado de ConcreteSubject e implementa la interfaz Update() de Observer que permite que dichas copias se conserven al paso. ConcreteObserver automáticamente despliega el estado y refleja los cambios siempre que se actualice el estado.El modelo UML del patrón se ilustra en la figura Consecuencias: El sujeto sólo conoce al Observer abstracto y no los detalles de la clase concreta. Por lo tanto, existe un acoplamiento mínimo entre dichos objetos. Debido a esta falta de conocimiento, son imprácticas las optimizaciones que mejoran el rendimiento del despliegue. Los cambios al sujeto podrían generar un conjunto de actualizaciones vinculadas a observadores, de las cuales algunas quizá no sean necesarias

detalles a la descripción de la solución. La figura 7.12 es la representación en UML delpatrón Observer.Para usar patrones en su diseño, se debe reconocer que cualquier problema de diseñoque enfrente es posible que tenga un patrón asociado para aplicarse. Los ejemplos detales problemas, documentados en el libro de patrones original de la “Banda de los cuatro”,incluyen:

1. Señalar a varios objetos que cambiaron el estado de algún otro objeto (patrónObserver).2. Ordenar las interfaces en un número de objetos relacionados que a menudo se hayandesarrollado incrementalmente (patrón Façade, fachada).3. Proporcionar una forma estándar para ingresar a los elementos en una colección, sinimportar cómo se implementó dicha colección (patrón Iterator, iterador).4. Permitir la posibilidad de extender la funcionalidad de una clase existente en tiempode operación (patrón Decorator, decorador).

1. Señalar a varios objetos que cambiaron el estado de algún otro objeto (patrón Observer).2. Ordenar las interfaces en un número de objetos relacionados que a menudo se hayan desarrollado incrementalmente (patrón Façade, fachada).3. Proporcionar una forma estándar para ingresar a los elementos en una colección, sin importar cómo se implementó dicha colección (patrón Iterator, iterador).4. Permitir la posibilidad de extender la funcionalidad de una clase existente en tiempo de operación (patrón Decorator, decorador).