Algoritmos y Programación III

Presentación del tema: "Algoritmos y Programación III"— Transcripción de la presentación:

1 Algoritmos y Programación III
7. Diseño, primeros patrones, MVC Carlos Fontela, 2006

2 Temario Diseño OO y patrones Presentación de patrones de uso habitual
Iterador Factory Method Template Method MVC y Observador

3 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

4 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

5 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

6 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.

7 Diseño de IU O Diseño externo Usabilidad y demás
Ver diapositivas en sitio web ¡Pero verlas!

8 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

9 Diseño de clases Clases de diseño Clases de implementación
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

10 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?

11 Iterador en Java

12 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

13 Iterador: consecuencias (II)
Soporte de recorridos diferentes O simultáneos Cambiando la clase de iterador No en Java, sí en C++

14 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

15 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

16 Iterador: UML

17 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

18 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()?

19 Template method: UML

20 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

21 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

22 Template Method: usos Applets de Java Arrays.sort (Comparable[])
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

23 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

24 Diseño de arquitectura: MVC
Se suele combinar con otros Bueno en aplicaciones de mucha IU Ventajas Facilitar cambios Muchas vistas por cada modelo

25 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

26 Observador: uso

27 Observador: estructura

28 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

29 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

30 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

31 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)

32 Observador en java.util (I)

33 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

34 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

35 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

36 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

37 Qué sigue Diseño de interfaces de usuario Patrones de diseño
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

38 Muchas Gracias. Carlos Fontela, 2006