Download Observable
Document related concepts
no text concepts found
Transcript
Algoritmos y Programación III 7. Diseño, primeros patrones, MVC Carlos Fontela, 2006 Temario Diseño OO y patrones Presentación de patrones de uso habitual Iterador Factory Method Template Method MVC y Observador Qué es diseño Es el “cómo” del desarrollo Fase más ingenieril del desarrollo de software • Lástima que se lo llame “arquitectura” Concebir una solución para un problema Entre el “qué” de los requerimientos y el producto terminado Propósito: crear una estructura interna clara y lo más simple posible Patrones Solución exitosa de un problema que aparece con frecuencia Patrones de diseño “Alguien ya ha resuelto nuestros problemas” Para problemas de diseño Patrones de programación Algoritmos “con nombre” • Métodos de ordenamiento, búsqueda Incluyen el algoritmo y una estructura de datos Uso de patrones Enseñanza Aplicación en distintos contextos Comprensión de partes de un sistema Comunicación con un vocabulario común Hay en otras ingenierías Qué diseñamos Despliegue en hardware Subsistemas o componentes de software y sus interacciones Integración con otros sistemas Interfaz de usuario Estructuras de datos Algoritmos Definiciones tecnológicas Plataforma, lenguaje, base de datos, etc. Diseño de IU O Diseño externo Usabilidad y demás Ver diapositivas en sitio web ¡Pero verlas! Diseño interno Arquitectura de componentes Arquitectura de despliegue Arquitectura de conectividad Diseño de datos Protocolos y dispositivos a usar Estructura de las bases de datos y la persistencia Software Lenguajes, herramientas y nomenclatura que se van a utilizar en la programación Diseño de clases Clases de diseño Describen conceptos de alto nivel Pertenecen al dominio de la solución Clases de implementación Surgen por necesidades algorítmicas, como un tipo de vector o árbol Para encontrarlas se aplican los conocimientos de algoritmos y estructuras de datos Patrones: creación de objetos Veamos Iterator i = v.iterator(); while (i.hasNext()) { ... i.next(); ... } ¿Por qué no hacemos: Iterator i = new ... Iterator es una interfaz ? ¿Dónde está la clase? ¿Ventajas? Iterador en Java Iterador: consecuencias (I) Simplifica la interfaz de la colección No hay recorridos No expone la estructura de la colección Cumple el principio de Única Responsabilidad Mantiene alta la cohesión Iterador: consecuencias (II) Soporte de recorridos diferentes O simultáneos Cambiando la clase de iterador No en Java, sí en C++ Iterador: implementación Control externo Cliente maneja el iterador mediante el método next() Muy flexible Control interno Iterador opera sobre los elementos, y controla el proceso Hay que decirle qué operación aplicar a los elementos Uso muy sencillo, implementación compleja Iterador como patrón La interfaz java.util.Iterator es muy útil Pero se puede extender si se desea También hay iteradores en otros lenguajes Pero si no los hubiera se podrían implementar Como cualquier patrón de diseño Iterador: UML Factory Method El caso de iterator() en Java Un método que crea instancias cuyo tipo es una interfaz o una clase abstracta Se mantiene una jerarquía de clases creadoras paralela a la jerarquía de clases a crear Template Method: polimorfismo Template Method es el uso crudo del polimorfismo Se basa en encapsular trozos de algoritmos Se lo llama también Application Framework: ¿se ve por qué? Ejemplo conocido: clase Thread ¿Por qué redefinimos run() e invocamos a start()? Template method: UML Template Method: varios (I) Los métodos a redefinir pueden ser abstractos en la clase plantilla O ser simples ganchos (“hooks”) con una implementación vacía o por defecto El método plantilla debería ser final Controla la lógica del algoritmo Es un marco o framework Los cambios deberían afectar solamente a los métodos redefinibles, que son los que definen los detalles Template Method: varios (II) La clase plantilla delega en subclases la implementación de los detalles Brinda un marco general, esqueleto o armazón Decide cuándo y cómo utilizar las clases descendientes Granularidad => Flexibilidad Pero más difícil de implementar Salvo que se usen implementaciones por defecto Template Method: usos Applets de Java Muchos puntos de extensión, con implementaciones por defecto Métodos init(), start(), destroy(), etc. Arrays.sort (Comparable[]) Se debe definir compareTo() Pero no mediante herencia Patrones: principios Encapsular lo que varía Preferir la composición a la herencia Programar usando interfaces, no implementaciones Bajo acoplamiento en la interacción entre objetos Mantener las clases abiertas para extensión y cerradas para modificación Una sola responsabilidad por clase Diseño de arquitectura: MVC Se suele combinar con otros Bueno en aplicaciones de mucha IU Ventajas Facilitar cambios Muchas vistas por cada modelo Observador: presentación (I) Paradigma de publicador - suscriptor. Para manejo de eventos Para MVC Para mensajería Hay dos objetos: Observador (pueden ser varios) Observado o sujeto Cambios en el estado de Observado provocan cambios en Observador Observador: uso Observador: estructura Observador: consecuencias Bajo acoplamiento entre sujeto y observadores El sujeto no se preocupa de los observadores Ni cambia si se registran observadores de tipos diferentes Lo único que sabe es que implementan una determinada interfaz Los observadores se suscriben y desuscriben libremente a una lista de referencias Soporte de broadcasting Agregado y remoción dinámica de observadores Observador: implementación Lo típico Guardar lista de observadores en sujeto Actualizaciones se materializan al cambiar estado del sujeto • Posiblemente provoque muchos update() Ojo Referencias colgadas en lenguajes sin recolección de basura Observador: variantes (I) Modelo “push” Sujeto envía toda la info que requieren los observadores Mayor acoplamiento: provoca una interfaz de observador específica Se envía información detallada, sin importar la incumbencia para los observadores Observador: variantes (II) Modelo “pull” Sujeto no envía info, sólo notifica Observadores consultan luego lo que les interesa Puede ser ineficiente Bien desacoplado Modelo con eventos Se registran observadores sólo para ciertos eventos o temas (uno o más) Observador en java.util (I) Observador en java.util (II) Definir una clase descendiente de Observable (que es una clase), para hacer de sujeto: que ante determinados cambios, invoque los métodos setChanged y notifyObservers Si no se llamó a setChanged, notifyObservers no invoca los update En general los métodos de Observable no se redefinen Construir una clase que implemente Observer, implementando el método update Observador en java.util (III) ¡Pero Observable es una clase! setChanged es protegido Y Java admite herencia simple Imposible extender un sujeto de otra clase de dominio Tampoco se puede implementar los sujetos de otra manera que no sea la de java.util Sólo puedo implementarlo en subclases No puedo utilizar composición java.util.Observable no es muy útil Hay alternativas en JavaBeans y en AWT Resumen El diseño ha sido revalorizado con la OO Incluye diseño de arquitecturas y de clases Diseño debe mantenerse sencillo y claro Observador Desacopla un sujeto observado de observadores MVC Desacopla vista, modelo y controlador Bibliografía La Web UML y patrones Orientación a objetos con Java y UML Craig Larman Carlos Fontela Enterprise Solution Patterns Using Microsoft .NET En MSDN, Patterns and Practices Qué sigue Diseño de interfaces de usuario Ver en la web ¡verlo! Patrones de diseño Vuelta a programación Concurrencia Buen código OO Aplicaciones distribuidas e integración de aplicaciones Muchas Gracias. Carlos Fontela, 2006