Algoritmos y Programación III 8. Patrones de despliegue, arquitectura y GoF Carlos Fontela, 2006

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

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

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

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

Arquitecturas y UML (I) Diagrama de despliegue

Arquitecturas y UML (II) Diagrama de componentes

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

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

Patrones de N capas: ejemplo

Patrones de N capas ++

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)

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}

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

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

Entrada y salida en Java (I)

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

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

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();

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;

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

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

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

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

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

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"));

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

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

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?

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

Decorador: solución (I)

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

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 = 1500.0; public TechoCorredizo (Auto comp) { super(comp); } return basico.costoTotal() + costo; public class AireAcondicionado extends DecoradorOpcionales { …

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

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

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

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

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

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

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

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

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

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

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

Muchas Gracias. Carlos Fontela, 2006