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
8. Patrones de despliegue, arquitectura y GoF Carlos Fontela, 2006

2 Temario Patrones de despliegue Patrones de componentes Persistencia
3 capas y N capas Persistencia Enfoque, formas de encararla Serialización, bases de datos Patrones muy comunes Decorador Otros patrones

3 Arquitectura de despliegue
Cómo se despliega un sistema en el hardware Aplicaciones stand-alone El sistema está desplegado enteramente en la máquina del usuario Aplicaciones distribuidas El usuario accede a un sistema corriendo parcialmente en una máquina remota Las máquinas remotas pueden ser varias

4 Patrones: cliente - servidor
Ventajas Especialización de equipos Seguridad, en algunos casos Si es web... Más sencillos despliegue y actualización

5 Patrones: tres capas Capas = Tiers Ventajas Muy “de moda”
Ídem anterior, ampliadas Muy “de moda”

6 Arquitecturas y UML (I)
Diagrama de despliegue

7 Arquitecturas y UML (II)
Diagrama de componentes

8 Arquitecturas de componentes
Simplemente arquitectura Descripción de componentes de software y sus interacciones Separación garantiza posibilidad de cambios Generalmente basada en patrones MVC 3 capas N capas Combinables con las anteriores Por lo tanto, independientes

9 Patrón de 3 capas No confundir con homónimo de despliegue Ventajas
Interfaz de usuario Modelo de negocio Acceso a datos Acceso a datos (DAL) No confundir con homónimo de despliegue Capas = layers Ventajas Cambios en IU y DAL Varios IU o DAL Otras interfaces

10 Patrones de N capas: ejemplo

11 Patrones de N capas ++

12 Capa de acceso a datos También DAL Dos enfoques “Data Access Layer”
Como persistencia de objetos (diseño orientado a objetos) Como abstracción de la base de datos (diseño por datos)

13 Persistencia Capacidad de un objeto de trascender el tiempo o el espacio Guardar el estado de un objeto Enviar un objeto por una red Debiera ser transparente Y no lo es casi nunca Separación de identidad y estado En diagrama de clases de UML {persistent}

14 Persistencia y agregación
Simple Casi siempre incorrecta Persistir sólo el objeto principal, con sus referencias Polimórfica Mantiene referencias y valores Isomórfica Recuperación sin conocer el tipo

15 Serialización Cadenas de bytes XML Soportada en varios lenguajes
Java, .Net Multiplataforma si lo es el lenguaje No es multilenguaje XML Con APIs especiales en cada lenguaje: SAX, DOM, JDOM, dom4j Multiplataforma y multilenguaje

16 Entrada y salida en Java (I)

17 Entrada y salida en Java (II)
Ejemplo: BufferedReader entrada = new BufferedReader (new FileReader("Datos.txt")); while ( (s = entrada.readLine()) != null) System.out.println(s); entrada.close(); Cambios en 1.4 A java.io se le agrega java.nio Mejor desempeño Mejor soporte de redes

18 Serialización en Java (I)
Implementar java.io.Serializable Cáscara vacía Permite al compilador generar información de serialización Evita el lanzamiento de NotSerializableException Por el resto es automático y permite usar ObjectOutputStream y ObjectInputStream para leer y escribir

19 Serialización en Java (II)
Ejemplo: class Fraccion implements Serializable { // … public void serializar (String archivo) throws IOException { ObjectOutputStream salida = new ObjectOutputStream( new FileOutputStream(archivo)); salida.writeObject(this); } public Fraccion hidratar (String archivo) throws IOException,ClassNotFoundException { ObjectInputStream entrada = new ObjectInputStream( new FileInputStream(archivo)); return (Fraccion)entrada.readObject();

20 Serialización en Java (III)
Realiza persistencia isomórfica Si las clases de los objetos contenidos implementan Serializable Si las clases ancestros implementan Serializable Y persistencia polimórfica Si se usa reflexión Object o = entrada.readObject(); if (o.getClass() == Fraccion.class) Fraccion z = (Fraccion)o;

21 Serialización .Net .Net tiene una anotación (“atributo”) Serializable
Semántica similar a Java

22 Persistencia y bases de datos
Vimos que la persistencia no necesariamente se hace sobre bases de datos Pero las bases de datos son centrales en las organizaciones

23 Bases de datos y OO (I) La BDR no es OO
Problemas con identidad de objetos No almacena objetos, con atributos y comportamiento Pero se usa en el 90% de las aplicaciones corporativas Se construye una capa filtrante que haga el cambio de paradigma De eso estamos hablando: DAL

24 Bases de datos y OO (II) BDOO Ejemplos Definición imprecisa
Sin éxito comercial destacable Muchas ni siquiera soportan herencia y polimorfismo Ejemplos Gemstone, Objective/DB, ObjectStore, Ontos, O2, Itasca, Matisse, Versant, Poet, Objectivity, db4o

25 Visión J2EE Es la más audaz
Propone que todo EJB de tipo “CMP entity” mantenga su estado en un repositorio permanente sin que el programador se deba preocupar de ello Con bases de datos relacionales o no Fuertes críticas Restricciones sobre el modelo de clases Dificultades de implementación Bajo desempeño

26 Bases de datos y Java JDBC Ejemplo, luego de compleja inicialización:
SQL multiplataforma desde Java  Paquete java.sql Ejemplo, luego de compleja inicialización: ResultSet r = s.executeQuery("SELECT NOMBRE, APELLIDO FROM alumnos WHERE TELEFONO Is Not Null ORDER BY APELLIDO"); // iteramos para encontrar los resultados: while (r.next()) // r es una especie de iterador System.out.println(r.getString("APELLIDO")+", "+r.getString("NOMBRE"));

27 Frameworks de persistencia (I)
Se ocupan de hacer un mapeo del mundo de los objetos al mundo relacional “O/R-mapping” Generalmente trabajan con archivos XML que definen cómo se hace el mapeo Muchas soluciones comerciales muy buenas Ahorran mucho trabajo A veces me evitan desarrollar la DAL

28 Frameworks de persistencia (II)
Casos Hibernate JDO OJB DataObjects Varios más Cuando no son suficientes, puedo construir mi propio framework

29 Decorador: presentación (I)
Para agregar responsabilidades dinámicamente Respetando el principio abierto-cerrado 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?

30 Decorador: presentación (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! Otra: atributos booleanos Diseño difícil de cambiar (p.ej. nuevos opcionales) Solución con Decorador: Diseño inicial más complejo Más escalable

31 Decorador: solución (I)

32 Decorador: solución (II)
public interface Auto { double costoTotal(); } public class Sedan implements Auto { private double costo = ; public double costoTotal() { return costo; } }   public class Familiar implements Auto { private double costo = ; } }

33 Decorador: solución (III)
public abstract class DecoradorOpcionales implements Auto { protected Auto basico; public Decorador (Auto comp) { basico = comp; } public double costoTotal() { return basico.costoTotal(); } } public class TechoCorredizo extends DecoradorOpcionales { private double costo = ; public TechoCorredizo (Auto comp) { super(comp); } return basico.costoTotal() + costo; public class AireAcondicionado extends DecoradorOpcionales { …

34 Decorador: solución (IV)
Instanciación: Auto 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

35 Decorador: uso general
Agregar comportamiento a métodos de un objeto Antes o después de llamarlos Mediante envoltorios a la clase servidora (“wrappers”) Ejemplo Clases de java.io

36 Decorador: otro ejemplo (I)
Supongamos que deseo contar cada vez que se llama el método dibujar en cualquier clase

37 Decorador: otro ejemplo (II)
Solución con Decorador: Figura f = new Contador (new Elipse() );

38 Decorador: otro ejemplo (III)
¿Pero, cómo nos aseguramos de que siempre asocie un Contador a cada Figura creada? Podemos encapsular la creación de figuras y allí envolver cada objeto en un Decorador Esto es otro patrón

39 Otros patrones habituales (I)
Estrategia Permite variar dinámicamente un algoritmo Adaptador Adapta un servicio para usarlo desde una clase Fachada Simplifica el acceso (interfaz) a varios servicios de un subsistema

40 Otros patrones habituales (II)
Proxy Objeto intermediario con la misma interfaz que el objetivo Estado o State Cuando cambia el estado de un objeto, que cambie su comportamiento Compuesto o Composite Para definir objetos compuestos con la misma interfaz que sus componentes

41 Otros patrones habituales (III)
Muchos más GoF Orden Memento Fábrica abstracta Son 23… Muchos más de otros autores-recopiladores MVC es un patrón compuesto Patrones de Larman

42 Resumen Arquitecturas DAL: dos enfoques
Facilitar cambios y modificaciones DAL: dos enfoques Persistencia de objetos Abstracción de BD BDR se usan a través de un mapeo O/R Decorador Agrega comportamiento antes o después de la llamada a un método

43 Qué sigue Vuelta a programación Concurrencia Buen código OO
Aplicaciones distribuidas e integración de aplicaciones

44 Bibliografía y otras fuentes
Patrones de diseño Gamma et al. Head-First Design Patterns Eric Freeman – Elisabeth Freeman UML y patrones Craig Larman Orientación a objetos con Java y UML Carlos Fontela

45 Muchas Gracias. Carlos Fontela, 2006