Upload
maria-elena-torregrosa-reyes
View
218
Download
0
Embed Size (px)
Citation preview
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 “Alguien ya ha resuelto nuestros problemas”
Patrones de diseño 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
Protocolos y dispositivos a usar Diseño de datos
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
VeamosIterator 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! 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 setChanged es protegido
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
Craig Larman
Orientación a objetos con Java y UML 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