View-Handler
Pattern Oriented Software Architecture View-Handler Jamir Antonio Avila Mojica César Julio Bustacara Medina Patrones de Software Agenda Introducción View-Handler Ejemplo Contexto Problema Solución Estructura Dinámica Implementación Variantes Usos conocidos Consecuencias View Handler • El patrón de diseño View Handler ayuda a administrar todas las vistas que proporciona un sistema de software. Un componente view handler permite a los clientes abrir, manipular y disponer las vistas. También coordina las dependencias entre ellas y orquesta su actualización. Ejemplo • Muchos editores de múltiples documentos permiten trabajar simultáneamente con varios documentos; cada documento se muestra en su propia ventana. Para usar efectivamente tales editores, los usuarios necesitan funcionalidad que les permita administrar tales ventanas. Por ejemplo, pueden querer clonar una ventana para trabajar con vistas independientes del mismo documento. Además, los usuarios no acostumbran cerrar las ventanas antes de salir del editor. Es tarea del sistema mantener la pista de todos los documentos abiertos y cerrarlos apropiadamente. Ejemplo Ejemplo • Así mismo, los cambios en una ventana pueden afectar a otras. Se requiere entonces de un mecanismo eficiente para propagar los cambios entre ventanas. Contexto • Un sistema de software que proporciona múltiples vistas de datos específicos de una aplicación, o que permite trabajar con múltiples documentos. Problema • Los sistemas de software que soportan múltiples vistas con frecuencia necesitan de funcionalidad adicional para administrarlas. Los usuarios quieren abrir, manipular, y disponer de las vistas y sus contenidos con facilidad. Las vistas deben estar coordinadas para que la actualización en una de ellas se propague automáticamente a las vistas relacionadas. Problema Fuerzas que gobiernan la solución de este problema: – Administrar múltiples vistas debe ser fácil desde la perspectiva del usuario, y también para los componentes cliente del sistema. – Las implementaciones de vistas individuales no dependen de las otras ni están mezcladas con el código usado para administrar las vistas. – Las implementaciones de las vistas pueden variar, y tipos adicionales de vistas se pueden adicionar durante la vida del sistema. Solución • Separe la administración de las vistas del código requerido para presentar o controlar vistas específicas. Un componente view handler administra todas las vistas que el sistema proporciona. Además, ofrece la funcionalidad necesaria para abrir, coordinar, cerrar vistas específicas, y también para organizarlas. Por ejemplo, una opción que permita disponer las vistas en un orden específico. Vistas específicas, junto con la funcionalidad para su presentación y control, son encapsuladas en componentes vista independientes – uno para cada tipo de vista. Suppliers proporcionan vistas con los datos que deben presentar. Solución • El patrón Value Handler adapta la idea, propuesta por el patrón MVC, de separar la presentación de la funcionalidad central. Por sí solo no proporciona una estructura completa para el sistema, sino que remueve la responsabilidad de administrar las vistas y sus dependencias mutuas del modelo y de los componentes vista. El patrón asigna esta responsabilidad al administrador de vistas. Por ejemplo, una vista no necesita manejar sus subvistas. El patrón View Handler es de granularidad más fina que el patrón ModelView-Controller – ayuda a refinar las relaciones entre el modelo y sus vistas asociadas. Solución Se puede considerar al componente view handler como un Abstract Factory y como un Mediator. Es un Abstract Factory puesto que los clientes son independientes de cómo son creadas las vistas específicas; es un Mediator porque los clientes no tienen conocimiento de cómo se coordinan las vistas. Solución En Enelelejemplo ejemplodel deleditor editorde dedocumentos, documentos,hay hayun uncomponente componentevista vista por porcada cadatipo tipode deventana ventanaasociada asociadacon conun undocumento. documento.El Elsistema sistema proporciona proporcionaventanas ventanaspara paraeditar editardocumentos, documentos,para paraprevisualizar previsualizarlala salida salidaimpresa, impresa,yypara paraver verimágenes imágenespreliminares preliminarespequeñas pequeñasde delas las páginas. páginas.Un Unview viewhandler handleradministra administraestas estasvistas. vistas.Además Ademásde delala creación creaciónyyeliminación eliminaciónde devistas, vistas,elelview viewhandler handlerofrece ofrecefunciones funciones que quepasan pasanaaprimer primerplano planouna unaventana, ventana,para paraclonarla, clonarla,yytambién también puede puedeacomodar acomodarlas lasventanas ventanaspara paraque queno nose setraslapen traslapencomo comoen enun un mosaico. mosaico.Los Losproveedores proveedoresde delas lasventanas ventanasson sonlos losdocumentos documentosaa desplegar. desplegar.Se Sepueden puedentener tenermúltiples múltiplesvistas vistassimultáneas simultáneasde deun un documento, documento,yytambién tambiénse sepueden puedenvisualizar visualizarmúltiples múltiplesdocumentos. documentos. Estructura • El view handler es el componente central del patrón. Es responsable de abrir nuevas ventanas, y los clientes pueden especificar la vista que quieren. El view handler instancia el componente vista correspondiente, se asegura de su correcta inicialización, y pide a la nueva vista que se muestre. Si la vista solicitada ya está abierta, el view handler la trae a primer plano. Si la vista solicitada está abierta pero minimizada, el view handler pide a la vista que se despliegue de tamaño regular. Estructura El view handler también ofrece funciones para cerrar vistas individuales o todas las vistas abiertas, como sea requerido por la aplicación cuando se cierre. Sin embargo, la principal responsabilidad del view handler, es ofrecer servicios de administración de vistas. Ejemplos incluyen funciones para traer rápidamente una vista específica a primer plano, acomodar vistas, dividir vistas individuales en partes, refrescar las vistas, y clonar las vistas para proporcionar varias vistas del mismo documento. Tal funcionalidad de administración puede ser difícil de organizar si su implementación abarcara muchos componentes vista diferentes. Estructura CRC de la clase View Handler Estructura • Una responsabilidad adicional del view handler es la coordinación. Puede haber dependencias entre vistas como sucede si varias vistas presentan diferentes partes de un documento compuesto. Tales vistas deben ser colocadas al lado unas de otras cuando son organizadas las ventanas. Si un usuario modifica una vista del documento, puede ser necesario actualizar las otras en un orden predefinido. Por ejemplo, las vistas que muestran la información más global deberían ser actualizadas en primer lugar. Estructura • Un componente abstract view define una interfaz que es común a todas las vistas. El view handler usa esta interfaz para crear, coordinar y cerrar las vistas. La plataforma en la que el sistema corre usa la interfaz para ejecutar eventos del usuario: como cambiar el tamaño de una ventana. La interfaz abstract view debe ofrecer la correspondiente función para todas las posibles operaciones que pueden ser ejecutadas en una vista. Estructura • Componentes specific view son derivados de abstract view e implementan esta interfaz. Adicionalmente, cada vista implementa su propia función de presentación. Recupera los datos del proveedor de la vista, prepara los datos para ser presentados, y los muestra al usuario. La función de presentación es invocada cuando se abre o actualiza una vista. Estructura CRC de las clases Abstract View y Specific View Estructura • Componentes Supplier proporcionan los datos que son presentados por los componentes vista. Estos Suppliers ofrecen una interfaz que permite a los clientes – las vistas – recuperar y cambiar los datos. Notifican a componentes dependientes sobre los cambios en su estado interno. Tales componentes dependientes son vistas individuales o, en el caso donde el view handler organice las actualizaciones, el view handler. Estructura Diagrama CRC de la clase Supplier Estructura Diagrama de clases OMT del patrón View Handler Dinámica Diagrama de secuencia del escenario 1 Implementación La implementación de una estructura View Handler se puede dividir en cuatro pasos. Se parte de que existen los proveedores, e incluyen un mecanismo de propagación de cambios. 1. Identifique las vistas. Especifique los tipos de vistas a ser proporcionados y como controla el usuario cada vista individual. Implementación 2. Especifique una interfaz común para todas las vistas. Incluya funciones para abrir, cerrar, presentar, actualizar, y manipular una vista. La interfaz puede ofrecer una función para inicializar una vista, que puede ser usada para configurar una vista con datos de un proveedor particular. Encapsule la interfaz en una clase abstracta, es posible proveer una implementación predefinida para algunas funciones. Implementación 3. Implemente las vistas. Derive una clase a partir de la clase AbstractView para cada tipo específico de vista identificado en el paso 1. Implemente las partes de la interfaz específicas a la vista, como el método displayData(). Sobreponga aquellos métodos para los cuales la implementación predefinida no sea suficiente. Si el view handler implementa políticas específicas de coordinación y actualización, las vistas deben notificar aquellos eventos que puedan afectar a otras vistas. Por ejemplo, partes previamente ocultas de otras vistas pueden volverse visibles cuando se cambia el tamaño de una vista. Si el view handler coordina la actualización de las vistas, debe ser notificado del cambio de tamaño (Publisher-Subscriber). Implementación 4. Defina el view handler. Implemente funciones para crear vistas como Factory Methods. Los clientes pueden especificar las vistas que quieren, pero no controlan cómo son creadas. El view handler es responsable de instanciar e iniciar el componente vista correcto. El view handler mantiene internamente referencias a todas las vistas abiertas. El patrón Iterator puede ayudar a implementar esta funcionalidad. El view handler también puede mantener información adicional sobre las vistas, como la posición actual y el tamaño de cada vista en la pantalla. Implementación El view handler puede necesitar implementar políticas de coordinación de vistas específicas de la aplicación. Por ejemplo, una vista puede desplegar información sobre otra vista, por ejemplo llevar una bitácora sobre una simulación animada. La organización de las vistas debe ubicar a estas dos vistas dependientes una al lado de la otra, o, si ambas vistas están minimizadas, la apertura de una debe abrir a la otra. Implementación Las estrategias de actualización son otro ejemplo de coordinación de vistas. Puede ser necesario, dar una mayor prioridad a la actualización de algunas vistas. Por ejemplo, aquellas vistas que muestran alarmas pueden necesitar se actualizadas antes que otras vistas. En tal caso, los proveedores notifican al view handler sobre los cambios antes que a las vistas dependientes. El view handler pasa estas solicitudes a las vistas afectadas usando su estrategia de actualización. Los view handler que coordinan la actualización de vistas ofrecen usualmente una función de actualización en su interfaz pública. Implementación Para permitir que las estrategias de coordinación sean intercambiables pueden ser implementadas con el patrón Strategy. El patrón de diseño Mediator ayuda en la implementación de la coordinación de vistas, por ejemplo difundiendo una solicitud de refresco a todas las vistas abiertas. Use el patrón Singleton para asegurar que no haya sino una instancia de la clase view handler. Variantes • View Handler con objetos Command. Esta variante usa objetos Command para mantener el view handler independiente de las interfaces de las vistas. En lugar de invocar directamente la funcionalidad, el view handler crea un comando apropiado y lo ejecuta. El command sabe como operar en la vista; por ejemplo, se puede especificar un comando organizar que, cuando sea ejecutado, primero invoque la función tamaño y luego la función mover de una vista. Otra opción es crear comandos y pasarlos a un Command Processor de comandos quien se encarga de su correcta ejecución, y también permite funcionalidad adicional como deshacer. Usos conocidos • Macintosh Window Manager. El Window Manager es parte del conjunto de herramientas Macintosh que puede ser comparado a un view handler. Su interfaz ofrece funciones para ubicación de ventanas, presentación, ubicación del ratón, movimiento de ventanas y cambio de tamaño, mantenimiento de una región de actualización. También proporciona una estructura de datos para cada ventana Macintosh. Como no ofrece funciones que operen en varias o en todas las ventanas, el MWM puede ser visto como un componente view handler de bajo nivel. Usos conocidos • Microsoft Word. El procesador de palabras de Microsoft ofrece funciones para clonar, dividir y organizar ventanas, y también para traer una ventana abierta a primer plano. Al salir de Word se cierran todas las ventanas abiertas; se despliegan diálogos solicitando la acción deseada si una ventana contiene datos que han sido cambiados pero no guardados. Este es un ejemplo de cómo un sistema View Handler puede lucir frente a un usuario, y la funcionalidad que proporciona. Ver también • El patrón de arquitectura Model-View-Controller proporciona una infraestructura para separar la funcionalidad del comportamiento de entrada y salida. Desde la perspectiva de MVC el patrón view handler es un refinamiento de la relación entre el modelo y sus vistas asociadas. • El patrón de arquitectura Presentation-Abstraction-Control implementa la coordinación de múltiples vistas de acuerdo con los principios del patrón view handler. Un agente PAC de nivel intermedio que crea y coordina vistas corresponde al view handler. Los agentes PAC de bajo nivel que presentan datos al usuario representan los componentes vista. Bibliografía • Buschmann Frank, Meunier Regine, Rohnert Hans, Sommerlad Peter, Stal Michael, Pattern Oriented Software Architecture: A System of Patterns, Volume One, Wiley, 1996
© Copyright 2024