algoritmos y programación iii 8. diseño, patrones, arquitecturas carlos fontela, 2004
TRANSCRIPT
Algoritmos y Programación III
8. Diseño, patrones,
arquitecturasCarlos Fontela, 2004
Página 2Algoritmos y Programación IIICarlos Fontela, 2004
Temario
Diseño OO
Arquitecturas
Arquitecturas y UML
Patrones de arquitectura de componentes Diseño de clases (en general) Cohesión y acoplamiento Patrones de diseño típicos
Página 3Algoritmos y Programación IIICarlos Fontela, 2004
Diseño
No es un simple epílogo del análisis Para el Proceso Unificado es más importante Para Extreme Programming es fundamental
Revalorizado en OO Incluye:
Las clases de diseño y las de implementación, con su estructura, operaciones y semántica.
Las distintas arquitecturas del sistema.
Página 4Algoritmos y Programación IIICarlos Fontela, 2004
Diseño de clases
Clases de diseño Si bien describen conceptos de alto nivel, como
las clases de análisis, no pertenecen al dominio del problema sino al 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.
Veremos más adelante.
Página 5Algoritmos y Programación IIICarlos Fontela, 2004
Arquitecturas (I)
De componentes Simplemente arquitectura. Idea de un diseño de sistema que consiste en
una descripción de sus principales componentes de software y sus interacciones.
Generalmente basada en patrones. De hardware
Despliegue de los distintos componentes en los nodos de hardware.
De conectividad Protocolos y dispositivos a usar.
Página 6Algoritmos y Programación IIICarlos Fontela, 2004
Arquitecturas (II)
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.
Interfaz de usuario Tipo de IU, elementos principales en cada caso,
relaciones entre ellos y normas de usabilidad.
Página 7Algoritmos y Programación IIICarlos Fontela, 2004
Arquitecturas y UML (I)
Consulta Catálogo Intranet Sistema Compras
Servicio Web CatálogoPáginas JSP
Clases de Negocio Catálogo (Java)
Sistema Ventas
iCatalogo
Interfaz Web XML SOAP
Base de datos de Catálogo
Diagrama de componentes
Página 8Algoritmos y Programación IIICarlos Fontela, 2004
Arquitecturas y UML (II)
Diagrama de despliegue
Servidor Base de Datos
Servidor de Aplicaciones
Servidor Web
Servidor ComercialPC Empleado
Consulta Catálogo Intranet
Sistema Compras
Servicio Web CatálogoPáginas JSP
Clases de Negocio Catálogo (Java)
Sistema Ventas
HTTP
Ethernet
HTTP
Ethernet
Base de Datos Catálogo
Página 9Algoritmos y Programación IIICarlos Fontela, 2004
Patrones de arquitectura
Separación garantiza posibilidad de cambios
Clásicos MVC 3 capas N capas
Especializados Sun para J2EE MS para aplicaciones distribuidas en .NET
Página 10Algoritmos y Programación IIICarlos Fontela, 2004
Patrón MVC
Ideal para aplicaciones stand-alone, con mucha IU
Basada en patrón Observador
Página 11Algoritmos y Programación IIICarlos Fontela, 2004
Patrón de 3 capas
Interfaz de usuario
Modelo de negocio
Acceso a datos
Interfaz de usuario
Modelo de negocio
Acceso a datos
Ideal para aplicaciones distribuidas
Página 12Algoritmos y Programación IIICarlos Fontela, 2004
Patrón de Sun para J2EE
Página 13Algoritmos y Programación IIICarlos Fontela, 2004
Patrón de MS para .NETInterfaz de usuario
Modelo de negocio
Acceso a datos
Seguridad
Adm
inistración Operativa
Com
unicación
Interfaz de usuario
Modelo de negocio
Acceso a datos
Seguridad
Adm
inistración Operativa
Com
unicación
Seguridad
Adm
inistración
Com
unicación
Componentes de la IU
Componentes de procesos de la IU
Servicios de IU
Flujos delmodelo
Componentesdel modelo
Entidadesdel modelo
Componentes lógicosde acceso a datos
Agentes deservicios
Seguridad
Adm
inistración
Com
unicación
Componentes de la IU
Componentes de procesos de la IU
Servicios de IU
Flujos delmodelo
Componentesdel modelo
Entidadesdel modelo
Componentes lógicosde acceso a datos
Agentes deservicios
Página 14Algoritmos y Programación IIICarlos Fontela, 2004
Bases del diseño de clases
Una buena arquitectura. Buenas prácticas de diseño y
programación. Patrones de diseño.
Eckel: “Un diseño termina cuando no se pueden
extraer más cosas del mismo.” “Las tareas más habituales se deben poder
hacer de una forma bien sencilla.”
Página 15Algoritmos y Programación IIICarlos Fontela, 2004
Clases
Cada clase con un propósito simple y claro: una clase por abstracción y una
abstracción por clase.
Separar las dependencias de una plataforma en una clase aparte.
Página 16Algoritmos y Programación IIICarlos Fontela, 2004
Patologías en diseño de clases
Clases con nombres verbales: No se supone que una clase hace algo, sino
que provee un conjunto de servicios. Clases sin métodos. Clases que no introducen nuevos métodos
ni los redefinen. Sólo heredan.
Clases que se refieren a varias abstracciones: Se deberían dividir en varias.
Página 17Algoritmos y Programación IIICarlos Fontela, 2004
Clases de asociación
Para representar atributos o comportamiento de las asociaciones.
Persona Empresa
periodo : Date
Empleo
* 0..1
Página 18Algoritmos y Programación IIICarlos Fontela, 2004
Cohesión y acoplamiento
Cohesión: Cada módulo haga una sola cosa simple.
Acoplamiento: Independencia entre módulos.
Asegurar bajo acoplamiento y alta cohesión en: Métodos Clases Paquetes
Algunos patrones ayudan.
Página 19Algoritmos y Programación IIICarlos Fontela, 2004
Interfaces de clases (I)
Es lo que ve el cliente Más clara Más consistente Más simple Más intuitiva
No quitar funcionalidad En Java: /** @deprecated */ “privatizar” lo más posible
Página 20Algoritmos y Programación IIICarlos Fontela, 2004
Interfaces de clases (II)
Implementar operaciones canónicas Comparable Serialización, toString() Clonación
Pocos parámetros No incluir opciones en métodos que realizan
acciones: Hacerlo en el constructor. O en forma sucesiva:
documento.establecerHoja(A4);
documento.establecerColor(rojo);
documento.imprimir();
Página 21Algoritmos y Programación IIICarlos Fontela, 2004
Atributos
Atributos deberían mostrar sólo estado y los métodos sólo comportamiento.
No abusar de la herencia para expresar estado: el color de una figura es un atributo.
Estado condicionado por los invariantes de clase: Se expresan como restricciones entre atributos. Conviene separar atributos vinculados en una clase
aparte que controle el cumplimiento de los invariantes.
Cuestiones de eficiencia nos pueden llevar a que no mantengamos siempre los invariantes de la clase.
Página 22Algoritmos y Programación IIICarlos Fontela, 2004
Métodos
Ojo con métodos con grandes switch en los que se hace una cosa u otra en base al valor de un atributo: if (unaFigura.getClass() == Elipse.class)
(Elipse)unaFigura.dibujar();
else if (unaFigura.getClass() == Poligono.class)
(Poligono)unaFigura.dibujar();
Habría que analizar el uso de herencia y polimorfismo.
O sobrecarga.
Página 23Algoritmos y Programación IIICarlos Fontela, 2004
Jerarquías (I)
Poner la mayor parte de los atributos y métodos lo más arriba que se pueda: para evitar luego definiciones duplicadas.
Si una porción de código se repite en muchas clases hermanas, habría que generar un método y ponerlo en la clase base.
Se puede generar un ancestro de todas las clases que tengan código en común. Sólo recomendable si se puede establecer la relación
“es un”.
Página 24Algoritmos y Programación IIICarlos Fontela, 2004
Jerarquías (II)
Evitar generalizar todo lo que parezca generalizable de entrada. Primero debemos resolver el problema que tenemos
entre manos de la manera lo más simple posible.
Una nueva clase descendiente debe añadir o redefinir un método (modificar la interfaz). Si no, no es necesaria. Riesgo de complicar la jerarquía sin un fin práctico. Tentación de especializar una clase en “varones” y
“mujeres” en vez de agregar un atributo booleano. Las jerarquías deben ayudar a dominar la complejidad,
no a complicarla.
Página 25Algoritmos y Programación IIICarlos Fontela, 2004
Jerarquías (III)
La herencia se debe usar sólo cuando la relación entre los conceptos sea permanente. Patrón “Estado abstracto” o “State”.
Es más sencillo describir una jerarquía de lo general a lo particular.
Pero esto no siempre se aplica a la construcción: Jerarquía construida por demanda.
Generalizaciones que surgen al descubrir atributos o métodos en común en clases ya construidas.
Sí para clases adquiridas.
Página 26Algoritmos y Programación IIICarlos Fontela, 2004
Excepciones a la herencia (I) Aves como animales voladores.
• ¿Pingüinos, gallinas, etc.? Idiomas de Europa como indoeuropeos.
• ¿magiar, finés y turco?
El uso de herencia con excepciones es una práctica cuestionable. Utilizar subclases para expresar las
excepciones. Pero las clasificaciones con subclases no
permiten excepciones por diferentes categorías.• No voy a poder clasificar a las aves también como
americanas y europeas sin caer en herencia repetida.
Página 27Algoritmos y Programación IIICarlos Fontela, 2004
Excepciones a la herencia (II)
Pocas soluciones en el terreno práctico. Herencia múltiple, en los lenguajes que la
manejan.
Interfaces cuando las excepciones se dan a
nivel de métodos.
Caso de discusión: ¿La circunferencia es una elipse con un radio
menos? ¿Cómo lo manejamos?
Página 28Algoritmos y Programación IIICarlos Fontela, 2004
Condiciones anormales (I)
Una excepción indica un error de
ejecución.
Mala idea elevar una excepción si no hay error.
Por ejemplo, si en una búsqueda no se
encontró el valor buscado.
Máxima: “Cuando todo falle, lance una
excepción”.
Página 29Algoritmos y Programación IIICarlos Fontela, 2004
Condiciones anormales (II)
“Un parámetro de error consume menos recursos”.
No nos guiemos por microeficiencias: privilegiar la robustez y la seguridad.
Las excepciones nos obligan a hacer algo con ellas: chequeo de condiciones lógicas puede evitarse,
dando la impresión de que no ha habido un error cuando en verdad lo hay.
Máxima del diseño robusto: “Nunca se debe dar la impresión de que no pasó nada cuando algo ha fallado”.
Página 30Algoritmos y Programación IIICarlos Fontela, 2004
Condiciones anormales (III)
Una implementación de clase debería venir con
las excepciones que puede disparar. Ponerlas en el mismo paquete.
Cuando se produce una excepción luego de
capturar recursos, a veces debemos liberarlos. El recolector de basura se va a ocupar de la memoria.
El resto los debe liberar el programador.
En el bloque finally.
Buena práctica: liberar en orden inverso a la adquisición.
Página 31Algoritmos y Programación IIICarlos Fontela, 2004
Diseño por contrato
Invento de Meyer.
Hay un contrato entre implementador y cliente basado en: Invariantes de clase.
Precondiciones de métodos.
Postcondiciones de métodos.
Implementado directamente en Eiffel. Facilidad para pasar de diseño a implementación.
Se centra más en qué hacen las clases que en cómo se hace.
Página 32Algoritmos y Programación IIICarlos Fontela, 2004
Patrones de diseño
Solución a un problema en un contexto. Indican cómo utilizar clases y objetos de formas
conocidas y estudiadas para adaptarlos a la resolución de parte de un
problema o a un escenario particular.
Reutilización llevada al diseño. Se aplica a una sociedad de clases. Se resuelve mediante una colaboración:
aspectos estructurales, aspectos de comportamiento.
Página 33Algoritmos y Programación IIICarlos Fontela, 2004
Patrones de diseño: usos
Colaboraciones probadas previamente. Fácil interpretación de diseños ya conocidos. Completitud frente a las soluciones caseras. Implementación directa
sin análisis y diseño complejos.
Facilidad de separar los aspectos que cambian de los que no cambian.
Lenguaje común para construir software y la enseñanza, el aprendizaje y el trabajo en grupos.
Página 34Algoritmos y Programación IIICarlos Fontela, 2004
Antipatrones de diseño
Diseños que han arruinado proyectos.
Para construir nuevos patrones.
Para no caer en ellos.
Interesante:http://www.hillside.net/patterns
http://www.enteract.com/~bradapp/docs/patterns-
intro.html
Página 35Algoritmos y Programación IIICarlos Fontela, 2004
Falsos patrones de diseño
Reutilización de código.
Soluciones a problemas puntuales. Generalmente se llega por buscar patrones a la fuerza.
Soluciones evidentes.
Interpretaciones de problemas sin su solución.
Soluciones que llegan a la implementación. Herramientas CASE modernas.
Hay excepciones: Singleton, Observador, Iterador, etc.
Página 36Algoritmos y Programación IIICarlos Fontela, 2004
Observador (I)
Paradigma de publicador - suscriptor. Para manejo de eventos. Para MVC. Para mensajería.
Hay dos objetos: Observador. Observado u Observable (pueden ser varios).
Cambios en Observado provocan cambios en Observador.
Página 37Algoritmos y Programación IIICarlos Fontela, 2004
Observador (II)
Implementado en java.util.
Clase o interfaz
Método Funcionalidad
Observable void setChanged() Marca que el objeto ha sido modificado. La función hasChanged va a devolver true.
Observable boolean hasChanged() Indica si el objeto ha sido modificado.Observable void clearChanged() Marca que el objeto no ha cambiado, o bien ya notificó a los observadores.
La función hasChanged va a devolver false.Observable void notifyObservers
(Object novedad)Si el objeto ha cambiado (hasChanged devuelve true), invoca a los métodos update de los observadores.
Observable void notifyObservers() Equivale a notifyObservers(null)Observable void addObserver
(Observer o)Agrega un observador a la lista.
Observable void deleteObserver (Observer o)
Elimina un observador de la lista.
Observable void deleteObservers (Observer o)
Elimina todos los observadores de la lista.
Observable int countObservers() Devuelve la cantidad de observadores de la lista.Observer void update (Observable
o, Object novedad)Es llamado automáticamente desde el notifyObservers de Observable cada vez que hay un cambio. Debe implementarse en la clase observadora.
Página 38Algoritmos y Programación IIICarlos Fontela, 2004
Observador (III)
Usando java.util.*: Definir una clase descendiente de Observable:• que ante determinados cambios, invoque los
métodos setChanged y notifyObservers. En general los métodos de Observable
no se redefinen. Construir una clase que implemente Observer,• implementando el método update.
Página 39Algoritmos y Programación IIICarlos Fontela, 2004
Observador (IV)
Observador consulta Observado cada tanto y se actualiza. Observador debe poder acceder a Observado. Sistemas de simulación. Sistemas que se manejan en base al tiempo.
“Estilo Java”: el observado envía un mensaje de actualización cada vez que modifica su estado. Sólo notifica cuando hay modificación digna de notificarse. El observado conoce a sus observadores y lo que necesitan.
Observado envía sólo una notificación de que hubo cambios. Observadores deben consultar al observado para ver qué cambió. Menos acoplado en un sentido y más en el otro.
Página 40Algoritmos y Programación IIICarlos Fontela, 2004
Decorador (I)
Objetos en capas, para agregar responsabilidades dinámicamente.
Ejemplo: un modelo de automóvil en tres variantes, llamadas
sedán, coupé y familiar, y cada variante tiene un precio básico de venta;
a cada variante se le pueden agregar opcionales como techo corredizo, aire acondicionado, sistema de frenos ABS, motor diesel y motor de 16 válvulas, y cada uno tiene un precio que se suma al básico;
cada auto podrá tener ninguno, uno o más opcionales.
¿Cómo calculamos los precios?
Página 41Algoritmos y Programación IIICarlos Fontela, 2004
Decorador (II)
Solución tradicional: herencia. Una clase para cada combinación
posible. Con 3 variantes y 5 opcionales, las
combinaciones posibles son 3 x 25 = ¡96 clases!
Solución con Decorador: Diseño inicial más complejo. Más escalable.
Página 42Algoritmos y Programación IIICarlos Fontela, 2004
Decorador (III)
«interface»ComponenteCliente
Sedan Familiar Coupe Decorador
TechoCorredizo AireAcondicionado ABS Diesel Valvulas16
Página 43Algoritmos y Programación IIICarlos Fontela, 2004
Decorador (IV)
public interface Componente {
double costoTotal();
}
public class Sedan implements Componente {
private double costo = 30000.0;
public double costoTotal() {
return costo;
} }
public class Familiar implements Componente {
private double costo = 40000.0;
public double costoTotal() {
return costo;
} }
Página 44Algoritmos y Programación IIICarlos Fontela, 2004
Decorador (V)public abstract class Decorador implements Componente {
protected Componente basico;
public Decorador (Componente comp) { basico = comp; }
public double costoTotal() {
return basico.costoTotal();
} }
public class TechoCorredizo extends Decorador {
private double costo = 1500.0;
public TechoCorredizo (Componente comp) { super(comp); }
public double costoTotal() {
return basico.costoTotal() + costo;
} }
public class AireAcondicionado extends Decorador { …
Página 45Algoritmos y Programación IIICarlos Fontela, 2004
Decorador (VI)
Instanciación:Componente a = new TechoCorredizo(
new AireAcondicionado(new Sedan()));
Un nuevo opcional Con herencia, 96 clases más Con Decorador, una clase más
Cambio del precio de un opcional Con herencia, 48 cambios Con Decorador, 1 cambio
Página 46Algoritmos y Programación IIICarlos Fontela, 2004
Singleton
Clase con una instancia única. Fácil de llevar a código:
final class Singleton {
private Object valor;
private static Singleton u = new Singleton ();
private Singleton() { valor = null; }
public static Singleton obtenerUnico() { return u; }
public Object obtenerValor() { return valor; }
public void darValor (Object x) { valor = x; }
}
Página 47Algoritmos y Programación IIICarlos Fontela, 2004
Pool de objetos
Extensión a Singleton para generar una cantidad finita de instancias.
Se debe poder eliminar objetos y colocarlos de nuevo en el pool.
Muy útil en aplicaciones distribuidas: conexiones a bases de datos referencias a instancias transacciones
Página 48Algoritmos y Programación IIICarlos Fontela, 2004
Proxy (I)
Apoderado o sucedáneo (surrogate). Un objeto que hace de interfaz de otro.
Con métodos similares. Los clientes tratan con un intermediario.
Aplicaciones: Proxy remoto: el objeto objetivo está en un sistema remoto.
Suele servir como caché o copia local. Proxy virtual: no se crea el objeto objetivo sino hasta que sea
realmente necesario, porque es costoso hacerlo. Proxy de protección: para controlar el acceso. Proxy de sincronización: para gestionar acceso de varios
clientes.
Página 49Algoritmos y Programación IIICarlos Fontela, 2004
Proxy (II)
Cliente Proxy Objetivo
a()
preProceso()
a()
postProceso()
a()
Página 50Algoritmos y Programación IIICarlos Fontela, 2004
Proxy (III)
+a()+b()+c()
«interface»BaseProxy
+a()+b()+c()+preProceso()+postProceso()
Proxy
+a()+b()+c()
Objetivo
1
1
1
1
Cliente
Página 51Algoritmos y Programación IIICarlos Fontela, 2004
Resumen
El diseño ha sido revalorizado con la OO Incluye diseño de arquitecturas y de clases Importante conocer los patrones de arquitectura Diseño debe mantenerse sencillo y claro Las clases deben tener estado y comportamiento Nunca se debe dar la impresión de que no pasó
nada cuando algo ha fallado. Los patrones llevan la reutilización al diseño. No son soluciones evidentes. Están suficientemente probados.
Página 52Algoritmos y Programación IIICarlos Fontela, 2004
Qué sigue
Diseño de interfaces de usuario Vuelta a Java
Concurrencia y persistencia Aplicaciones distribuidas, web y demás ¡Fin!
Página 53Algoritmos y Programación IIICarlos Fontela, 2004
Bibliografía y otras fuentes
Para MVC: http://www.enode.com/x/markup/tutorial/mvc.html
http://www.cica.es/formacion/JavaTut/Apendice/mvc.html
Para arquitecturas relacionadas con J2EE: http://java.sun.com/j2ee/tutorial/
Para arquitecturas relacionadas con .NET: http://www.microsoft.com/resources/practices/
Muchas Gracias.
Carlos Fontela, 2004