Algoritmos y Programación III 8. Diseño, patrones, arquitecturas Carlos Fontela, 2004.

Presentación del tema: "Algoritmos y Programación III 8. Diseño, patrones, arquitecturas Carlos Fontela, 2004."— Transcripción de la presentación:

1 Algoritmos y Programación III 8. Diseño, patrones, arquitecturas Carlos Fontela, 2004

2 Página 2Algoritmos y Programación III Carlos 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

3 Página 3Algoritmos y Programación III Carlos 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.

4 Página 4Algoritmos y Programación III Carlos 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.

5 Página 5Algoritmos y Programación III Carlos 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.

6 Página 6Algoritmos y Programación III Carlos 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.

7 Página 7Algoritmos y Programación III Carlos Fontela, 2004 Arquitecturas y UML (I) Diagrama de componentes

8 Página 8Algoritmos y Programación III Carlos Fontela, 2004 Arquitecturas y UML (II) Diagrama de despliegue

9 Página 9Algoritmos y Programación III Carlos 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

10 Página 10Algoritmos y Programación III Carlos Fontela, 2004 Patrón MVC Ideal para aplicaciones stand-alone, con mucha IU Basada en patrón Observador

11 Página 11Algoritmos y Programación III Carlos Fontela, 2004 Patrón de 3 capas Ideal para aplicaciones distribuidas

12 Página 12Algoritmos y Programación III Carlos Fontela, 2004 Patrón de Sun para J2EE

13 Página 13Algoritmos y Programación III Carlos Fontela, 2004 Patrón de MS para.NET

14 Página 14Algoritmos y Programación III Carlos 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.”

15 Página 15Algoritmos y Programación III Carlos 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.

16 Página 16Algoritmos y Programación III Carlos 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.

17 Página 17Algoritmos y Programación III Carlos Fontela, 2004 Clases de asociación Para representar atributos o comportamiento de las asociaciones.

18 Página 18Algoritmos y Programación III Carlos 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.

19 Página 19Algoritmos y Programación III Carlos 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

20 Página 20Algoritmos y Programación III Carlos 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();

21 Página 21Algoritmos y Programación III Carlos 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.

22 Página 22Algoritmos y Programación III Carlos 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.

23 Página 23Algoritmos y Programación III Carlos 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”.

24 Página 24Algoritmos y Programación III Carlos 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.

25 Página 25Algoritmos y Programación III Carlos 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.

26 Página 26Algoritmos y Programación III Carlos 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.

27 Página 27Algoritmos y Programación III Carlos 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?

28 Página 28Algoritmos y Programación III Carlos 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”.

29 Página 29Algoritmos y Programación III Carlos 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”.

30 Página 30Algoritmos y Programación III Carlos 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.

31 Página 31Algoritmos y Programación III Carlos 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.

32 Página 32Algoritmos y Programación III Carlos 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.

33 Página 33Algoritmos y Programación III Carlos 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.

34 Página 34Algoritmos y Programación III Carlos 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

35 Página 35Algoritmos y Programación III Carlos 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.

36 Página 36Algoritmos y Programación III Carlos 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.

37 Página 37Algoritmos y Programación III Carlos Fontela, 2004 Observador (II) Implementado en java.util.

38 Página 38Algoritmos y Programación III Carlos 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.

39 Página 39Algoritmos y Programación III Carlos 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.

40 Página 40Algoritmos y Programación III Carlos 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?

41 Página 41Algoritmos y Programación III Carlos 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 2 5 = ¡96 clases! Solución con Decorador: Diseño inicial más complejo. Más escalable.

42 Página 42Algoritmos y Programación III Carlos Fontela, 2004 Decorador (III)

43 Página 43Algoritmos y Programación III Carlos 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;}

44 Página 44Algoritmos y Programación III Carlos 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 { …

45 Página 45Algoritmos y Programación III Carlos 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

46 Página 46Algoritmos y Programación III Carlos 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; } }

47 Página 47Algoritmos y Programación III Carlos 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

48 Página 48Algoritmos y Programación III Carlos 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.

49 Página 49Algoritmos y Programación III Carlos Fontela, 2004 Proxy (II)

50 Página 50Algoritmos y Programación III Carlos Fontela, 2004 Proxy (III)

51 Página 51Algoritmos y Programación III Carlos 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.

52 Página 52Algoritmos y Programación III Carlos Fontela, 2004 Qué sigue Diseño de interfaces de usuario Vuelta a Java Concurrencia y persistencia Aplicaciones distribuidas, web y demás ¡Fin!

53 Página 53Algoritmos y Programación III Carlos 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/

54 Muchas Gracias. Carlos Fontela, 2004