1. Universidad Nacional de Trujillo
FACULTAD DE CIENCIAS FISICAS Y
MATEMATICAS
ESCUELA ACADÉMICO PROFESIONAL DE INFORMATICA
TOPICOS EN ING. DE SOFTWARE
TEMA
PROFESOR
ALUMNO
: PATRON DE SOFTWARE OBSERVER
: ING. ARTURO DIAZ PULIDO
: LUDWING EVANDER RUBIO NARRO
Trujillo – Perú
2014

2. INDICE
Pag.
Introducción
4
Marco Teórico
Capítulo I: Definición
5
Capitulo II: Objetivo
6
Capitulo III: Motivación
6
Capitulo IV: Aplicabilidad
6
Capítulo V: Estructura
7
Capítulo VI: Participantes
7
Capitulo VII: Colaboraciones
8
Capitulo VIII: Consecuencias
8
Conclusiones
9
Bibliografía
10

3. DEDICATORIA
Agradecemos primeramente a dios, por habernos dado la sabiduría, la inteligencia para
realizar este trabajo, por haber sido el quien por medio de nuestras familias estuvo junto a
nosotros en todo momento, a nuestros padres por habernos dado la ayuda afectiva, moral,
económica y ser nuestros apoyo y sustento en todo momento.
A nuestro profesor, el Ingeniero Arturo Diaz Pulido quien nos guió y nos instruyó por el
camino del conocimiento.

4. Introducción
Los patrones de diseño software de comportamiento son aquellos que están relacionados
con
algoritmos
y
con
la
asignación
de
responsabilidades
a
los
objetos.
Describen no solamente patrones de objetos o de clases, sino que también engloban
patrones de comunicación entre ellos. Al igual que los otros tipos de patrones, se pueden
clasificar en función de que trabajen con clases (Template Method, Interpreter) u objetos
(Chain of Responsability, Command, Iterator, Mediator, Memento, Observer, State,
Strategy, Visitor).
El patrón de comportamiento Observer define una interacción entre objetos, de manera
que cuando uno de ellos cambia su estado, el Observer se encarga de notificar este cambio
a los demás

5. PATRÓN DE DISEÑO SOTWARE OBSERVER
MARCO TEORICO
CAPITULO I : DEFINICION
Observador es un patrón de diseño que define una dependencia del tipo uno-amuchos entre objetos, de manera que cuando uno de los objetos cambia su estado,
notifica este cambio a todos los dependientes.
Se trata de un patrón de comportamiento (existen de 3 tipos: Creación, Estructurales y
de Comportamiento), es decir, está relacionado con algoritmos de funcionamiento y
asignación de responsabilidades a clases y objetos. Los patrones de comportamiento
describen no solamente estructuras de relación entre objetos o clases sino
también esquemas de comunicación entre ellos y se pueden clasificar en función de que
trabajen con clases (Método Plantilla) u objetos (Cadena de Responsabilidad, Comando,
Iterador, Recuerdo, Observador, Estado, Estrategia, Visitante).
La variación de la encapsulación es la base de muchos patrones de comportamiento, por
lo que cuando un aspecto de un programa cambia frecuentemente, estos patrones
definen un objeto que encapsula dicho aspecto. Los patrones definen una clase
abstracta que describe la encapsulación del objeto.
Este patrón también se conoce como el patrón de publicación-inscripción o modelopatrón. Estos nombres sugieren las ideas básicas del patrón, que son: el objeto de datos,
que se le puede llamar Sujeto a partir de ahora, contiene atributos mediante los cuales
cualquier objeto Observador o vista se puede suscribir a él pasándole una referencia a sí
mismo. El Sujeto mantiene así una lista de las referencias a sus observadores. Los
observadores a su vez están obligados a implementar unos métodos determinados
mediante los cuales el Sujeto es capaz de notificar a sus observadores suscritos los
cambios que sufre para que todos ellos tengan la oportunidad de refrescar el contenido
representado. De manera que cuando se produce un cambio en el Sujeto, ejecutado, por
ejemplo, por alguno de los observadores, el objeto de datos puede recorrer la lista de
observadores avisando a cada uno.

6. Este patrón suele observarse en los frameworks de interfaces gráficas orientados a
objetos, en los que la forma de capturar los eventos es suscribir listeners a los objetos
que pueden disparar eventos.
El patrón fue implementado por primera vez en Smalltalk's MVC basado en un
framework de interfaz. Este patrón está implementado en numerosos librerías y
sistemas, incluyendo todos los toolkits de GUI.
CAPITULO II : OBJETIVO
Definir una dependencia uno-a-muchos entre objetos, de tal forma que cuando el objeto
cambie de estado, todos sus objetos dependientes sean notificados automáticamente.
Se trata de desacoplar la clase de los objetos clientes del objeto, aumentando la
modularidad del lenguaje, creando las mínimas dependencias y evitando bucles de
actualización. En definitiva, normalmente, usaremos el patrón Observador cuando un
elemento “quiere” estar pendiente de otro, sin tener que estar encuestando de forma
permanente si éste ha cambiado o no.
CAPITULO III MOTIVACION
Si se necesita consistencia entre clases relacionadas, pero con independencia, es decir,
con un bajo acoplamiento. Muchas veces un efecto lateral de partir un sistema en una
colección de objetos relacionados es que necesitamos mantener la consistencia entre
objetos relacionados.
CAPITULO IV: APLICABILIDAD
Puede pensarse en aplicar este patrón cuando una modificación en el estado de un
objeto requiere cambios de otros, y no deseamos que se conozca el número de objetos
que deben ser cambiados. También cuando queremos que un objeto sea capaz de
notificar a otros objetos sin hacer ninguna suposición acerca de los objetos notificados y
cuando una abstracción tiene dos aspectos diferentes, que dependen uno del otro; si
encapsulamos estos aspectos en objetos separados permitiremos su variación y
reutilización de modo independiente.

7. CAPITULO V: ESTRUCTURA
Estructura patrón Observador
CAPITULO VI: PARTICIPANTES
Tendremos sujetos concretos cuyos cambios pueden resultar interesantes a otros y
observadores a los que al menos les interesa estar pendientes de un elemento y en un
momento dado, reaccionar ante sus notificaciones de cambio. Todos los sujetos tienen
en común que un conjunto de objetos quieren estar pendientes de ellos. Cualquier
elemento que quiera ser observado tiene que permitir indicar:
1.
“Estoy interesado en tus cambios”.
2.
“Ya no estoy interesado en tus cambios”.
El observable tiene que tener, además, un mecanismo de aviso a los interesados.
A continuación tenemos a los participantes de forma desglosada:

8. •
Sujeto (Subject): El sujeto concreto proporciona una interfaz para agregar
(attach) y eliminar (detach) observadores. El Sujeto conoce a todos sus
observadores.
•
Observador (Observer): Define el método que usa el sujeto para notificar
cambios en su estado (update/notify).
•
Sujeto Concreto (ConcreteSubject): Mantiene el estado de interés para los
observadores concretos y los notifica cuando cambia su estado. No tienen porque
ser elementos de la misma jerarquía.
•
Observador Concreto (ConcreteObserver): Mantiene una referencia al sujeto
concreto e implementa la interfaz de actualización, es decir, guardan la referencia
del objeto que observan, así en caso de ser notificados de algún cambio, pueden
preguntar sobre este cambio.
CAPITULO VII: COLABORACIONES
La colaboración más importante en este patrón es entre el sujeto y sus observadores, ya
que en el momento en el que el sujeto sufre un cambio, este notifica a sus
observadores.
Después de ser informado de un cambio en el objeto observado, cada observador
concreto puede pedirle la información que necesita para reconciliar su estado con el de
aquél.
CAPITULO VIII: CONSECUENCIA
Las consecuencias de aplicar este patrón pueden ser tanto beneficiosas como pueden
perjudicar algunos aspectos. Por una parte abstrae el acoplamiento entre el sujeto y el
observador, lo cual es beneficioso ya que conseguimos una mayor independencia y
además el sujeto no necesita especificar los observadores afectados por un cambio. Por
otro lado, con el uso de este patrón ocurre que vamos a desconocer las consecuencias
de una actualización, lo cual, dependiendo del problema, puede afectarnos en mayor o
menor medida (por ejemplo, al rendimiento).

9. CONCLUSIONES

La principal ventaja de este patrón es que todo se logra sin recurrir a un acoplamiento
estrecho.

El sujeto solo sabe de una lista de observadores y en una sola llamada los notifica.
Al sujeto no le interesa los efectos o desenlaces de los observadores, él simplemente
emite. El resultado es código flexible y reusable.

La única desventaja apreciable, aparece cuando un observador es demasiado grande.
Eso puede traer consecuencias en el uso de memoria.

La razón de ser de este patrón es desacoplar las clases de los objetos, aumentando la
modularidad del lenguaje y evitando bucles de actualización

El patrón Observer suele emplearse en el desarrollo de frameworks de interfaces
gráficas orientados a objetos

10. BIBLIOGRAFIA
http://patronesdediseno.net16.net/comportamiento.html
http://es.wikipedia.org/wiki/Observer_(patr%C3%B3n_de_dise%C3%B1o)
http://patronesdediseno.blogspot.com/2009/05/patron-observer.html
http://www.javacodegeeks.com/2013/08/observer-design-pattern-in-java-exampletutorial.html