Descargar

Diseño de Software – Observer, State y Visitor

Enviado por Pablo Turmero


Partes: 1, 2, 3

    edu.red 1 Observer / Publish-Subscribe (Observador) Propósito Define una dependencia uno-a-muchos entre objetos, de modo que cuando cambia el estado de un objeto, todos sus dependientes automáticamente son notificados y actualizados. Motivación ¿Cómo mantener la consistencia entre objetos relacionados, sin establecer un acoplamiento fuerte entre sus clases? Ejemplo: Separación Modelo-Vista

    edu.red (Gp:) 1tr (Gp:) 3tr (Gp:) 4tr (Gp:) 2tr

    (Gp:) 1tr. 2tr. 3tr. 4tr. Este 20 25 90 20 Oeste 30 38 32 32 Norte 47 47 45 45

    Vistas t1=20 t2=25 t3=90 t4=20 Modelo Motivación

    edu.red 3 Separación Modelo-Vista Los objetos del modelo (dominio) no deben conocer directamente a los objetos de la vista (presentación). Las clases del dominio encapsulan la información y el comportamiento relacionado con la lógica de la aplicación. Las clases de la interfaz (ventanas) son responsables de la entrada y salida, capturando los eventos, pero no encapsulan funcionalidad de la aplicación.

    edu.red 4 Separación Modelo-Vista Justificación Clases cohesivas Permitir separar el desarrollo de las clases de la vista y del dominio Minimizar el impacto de los cambios en la interfaz sobre las clases del modelo. Facilitar conectar otras vistas a una capa del dominio existente. Permitir varias vistas simultáneas sobre un mismo modelo. Permitir que la capa del modelo se ejecute de manera independiente a la capa de presentación.

    edu.red 5 Observer Estructura

    edu.red 6 Observer Colaboración

    edu.red 7 Observer Aplicabilidad Cuando un cambio de estado en un objeto requiere cambios en otros objetos, y no sabe sobre qué objetos debe aplicarse el cambio. Cuando un objeto debe ser capaz de notificar algo a otros objetos, sin hacer asunciones sobre quiénes son estos objetos.

    edu.red 8 Observer Consecuencias

    Acoplamiento abstracto y mínimo entre Subject y Observer: Subject no necesita conocer las clases concretas de observers permite modificar independientemente subjects y observers pueden reutilizarse por separado pueden añadirse observers sin modificar el subject

    edu.red 9 Observer Consecuencias Soporte para comunicación de tipo broadcast el subject no especifica al receptor concreto de la notificación es posible añadir y eliminar observers en cualquier instante Actualizaciones inesperadas. Una interfaz simple de Observer requiere que los observers tengan que deducir el ítem cambiado.

    edu.red 10 Observer Implementación Es posible que un observer esté ligado a más de un subject: la operación update tendrá como argumento el subject ¿Quién dispara la notificación? Métodos set en la clase Subject Clientes de la clase Subject Asegurarse de notificar con el estado de Subject consistente ¿Cuánta información sobre el cambio se le envía a los observers con la notificación? Modelo Push (Mucha) y Modelo Pull (Muy Poca)

    Partes: 1, 2, 3
    Página siguiente