Download Observable

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