71
Patrones de Diseño Arquitecturas de Software Marcelo Magaña

Patrones de Diseño

Embed Size (px)

Citation preview

Page 1: Patrones de Diseño

Patrones de DiseñoArquitecturas de Software

Marcelo Magaña

Page 2: Patrones de Diseño

¿Por qué patrones?

“Si los constructores hicieran las

casas de la misma forma en que los

programadores escriben código, el

primer pájaro carpintero que viniera

destruiría la civilización”

Page 3: Patrones de Diseño

¿Por qué patrones?

Si quisieran construir una casa, ¿cómo lo harían?

1. Buscar un árbol robusto

2. Conseguir madera, un martillo y clavos

3. Aplicar los productos del paso 2 al paso 1

4. Esperar lo mejor

Page 4: Patrones de Diseño

¿Por qué patrones?

Sería un mejor plan encontrar un Arquitecto que elabore los planos

Ahora bien………

¿Cómo toma las decisiones el Arquitecto?

No es diferente en el mundo del desarrollo de Software

Page 5: Patrones de Diseño

¿Por qué patrones?

Necesitamos un gurú del desarrollo de Sw◦No hay muchos gurús en el mundo◦Tenemos que valernos por nosotros mismos

¿Habrá una forma de agrupar todo ese conocimiento?◦Patrones de Diseño

Page 6: Patrones de Diseño

¿Por qué patrones?

Soluciones bien documentadas

Solucionar nuevos problemas

Aplicadas con éxito en el pasado

Problemas similares

Adaptar la solución previa al contexto actual

Desarrollar una forma estandarizada para

solucionar problemas comunes

Page 7: Patrones de Diseño

Un poco de Historia

Christopher Alexander◦Catedrático de Arquitectura de U.C. Berkeley◦Diversos Libros – Concepto de Patrón◦Captó interés

Kent Beck – Ward Cunningham◦Conjunto de patrones de diseño para Smalltalk◦OOPSLA – 1987

James Coplien◦Expresiones Comunes en C++◦Patrones para el desarrollo en C++

Page 8: Patrones de Diseño

OOPSLA

Object-Oriented Programming, Systems, Languages & Applications

◦Conferencia anual de la ACM (Association for

Computing Machinery)

◦Orlando, Florida

Page 9: Patrones de Diseño

Un poco de Historia

Patrones de Diseño◦Erich Gamma, Richard Helm, Ralph Johnson y

John Vlissides◦“Gang of Four” o GoF◦Ejemplos en C++

Pattern-Oriented Software Architecture, A Systems of Patterns◦Buschmann, Meunier, Rohnert, Somerland y

Stal

Page 10: Patrones de Diseño

Conceptos básicos

Los Patrones de Diseño se basan en un “Formulario” o “Formato”:

◦Nombre: Descriptivo

◦También conocido como: nombres alternativos

◦Propiedades: Clasificación del Patrón, según

dos aspectos

Page 11: Patrones de Diseño

Tipo

Patrones de Creación

◦Creación de Objetos

Patrones de Comportamiento

◦Interacción Funcional

Patrones Estructurales

◦Relaciones estáticas y estructurales

Patrones de Sistema

◦Interacción a nivel de Sistema

Page 12: Patrones de Diseño

Nivel

Clase Única

◦Aplica a una única clase

Componente

◦Grupo de Clases

Arquitectónico

◦Coordinar acciones de sistemas y subsistemas

Page 13: Patrones de Diseño

Conceptos básicos

Los Patrones de Diseño se basan en un “Formulario” o “Formato”:

◦Propósito: breve explicación de implicancias

◦Presentación: Desc. De problema afrontable

◦Aplicabilidad: Cuando y por qué

◦Descripción: explicación detallada

Page 14: Patrones de Diseño

Conceptos básicos

Los Patrones de Diseño se basan en un “Formulario” o “Formato”:

◦Implementación: qué debe hacerse para usarlo

◦Ventajas e Inconvenientes:

◦Variantes: implementaciones alternativas

◦Patrones relacionados

◦Ejemplo: trozo de código

Page 15: Patrones de Diseño

Patrones de Creación

Introducción

Abstract Factory

Builder

Factory Method

Prototype

Singleton

Page 16: Patrones de Diseño

Patrones de Creación

Facilitan la tarea de Crear Objetos

Proporcionan:

◦Instanciación Genérica

◦Simplicidad

◦Restricciones de Creación

Page 17: Patrones de Diseño

Instanciación Genérica

Crear Objetos sin identificar una clase

específica

“Generics” en Java.

Palabra reservada “instanceof”

Page 18: Patrones de Diseño

Simplicidad

Facilitan la creación de Objetos

No es necesario escribir grandes y

complejos códigos

Page 19: Patrones de Diseño

Restricciones de Creación

Algunos patrones fuerzan ciertas

restricciones

◦Tipo de Objetos

◦Número de Objetos

Page 20: Patrones de Diseño

Abstract Factory

También conocido como:◦Kit◦Toolkit

Propiedades:◦Tipo: creación, objeto◦Nivel: componente

Propósito◦Contrato para crear familias de objetos

relacionados o dependientes, sin clase concreta

Page 21: Patrones de Diseño

Abstract Factory

Gestionar información sobre direcciones y teléfonos

Combinación entre◦Libreta de Direcciones◦Agenda Personal◦Gestor de contactos◦Uso intensivo de datos

Crear clases para representar dirección y número de teléfono◦Address◦PhoneNumber

Page 22: Patrones de Diseño

Abstract Factory

Reglas de Negocios◦Teléfonos con 7 dígitos más dos dígitos por códigos de área

◦Código postal limitado a 6 dígitosGestionar datos de otros países

◦Diferentes reglas de gobierno para los datos

◦Modificar lógica de clases◦Recompilar las clases◦Código desbordado y frágil

Page 23: Patrones de Diseño

Abstract Factory

Solución:

◦Añadir clases de forma flexible al sistema

◦Tomar las reglas generales aplicables a todas

las direcciones y números

◦“Cargar” en el sistema cualquier variación

posible

Page 24: Patrones de Diseño

Abstract Factory

Aplicabilidad

◦Cliente independiente de creación de productos

◦Aplicación configurable con varias familias de

productos

◦Crear objetos como conjunto para compatibilizar

◦Proporcionar colección de clases, revelando sus

contratos y relaciones, no sus implementaciones

Page 25: Patrones de Diseño

Abstract Factory

Descripción:◦Aplicaciones usan varios recursos o sistemas

operativos Gestión de Ventanas (GUI) Sistema de Archivos Comunicación con otras aplicaciones o sistemas

◦Flexibles para utilizar distintos recursos sin reescribir código para un nuevo recurso

◦Java-distintas plataformas-implementaciones

Page 26: Patrones de Diseño
Page 27: Patrones de Diseño

Abstract Factory

Ejemplo:◦La Interfaz AddressFactory representa la fábrica

en si misma

Page 28: Patrones de Diseño

Abstract Factory

Page 29: Patrones de Diseño

Abstract Factory

Page 30: Patrones de Diseño

Abstract Factory

Page 31: Patrones de Diseño

Abstract Factory

Page 32: Patrones de Diseño

Abstract Factory

Page 33: Patrones de Diseño

Abstract Factory

Page 34: Patrones de Diseño

Abstract Factory

Page 35: Patrones de Diseño

Abstract Factory

Page 36: Patrones de Diseño

Singleton

Propiedades:◦Tipo: Creación◦Nivel: Objeto

Propósito:◦Crear una única instancia de la clase en el

sistema, mientras se permite que todas las clases tengan acceso a ella

Page 37: Patrones de Diseño

Singleton

Objeto global, accesible desde cualquier parte, creado una vez.

Dos opciones:◦Un objeto global que mantenga el Historial

(HistoryList)◦Crear valores globales usando variables

estáticas

Page 38: Patrones de Diseño

Singleton

Un objeto estático no basta, ya que se crea

cuando se carga la clase, y no ofrece datos

antes de ser instanciado.

No lleva control sobre quién accede al

objeto, cualquiera accede a instancia

públicamente disponible.

Si se modifica para Singleton, habrá que

modificar tooooodo el código cliente.

Page 39: Patrones de Diseño

Singleton

Aplicabilidad◦Una instancia de la clase disponible globalmente.

Descripción◦Asegura sólo una instancia de la aplicación en la

JVM, constructor privado.◦“getInstance()” accede a una instancia de esa

clase Crea una instancia única si no existe, y devuelve la

referencia a quien invoca el método La referencia también se almacena como un atributo

privado estático en la clase Singleton.

Page 40: Patrones de Diseño

Singleton

Implementación

Page 41: Patrones de Diseño

Singleton

Ventajas e Inconvenientes

◦Clase Singleton es la única que puede crear instancias

de si misma, no se puede obtener ninguna instancia

sin utilizar método estático.

◦No necesita pasar referencia a todos quienes acceden

a ella

◦Puede presentar problemas de “Multithread”, según

como se implemente.

◦Sin control apropiado, la aplicación entrará en una

“guerra de threads”

Page 42: Patrones de Diseño

Singleton

Ejemplo:

◦Disponer para los usuarios de una aplicación, la

posibilidad de deshacer los comandos

anteriores, este historial debe estar disponible

desde todas las partes de la aplicación.

Page 43: Patrones de Diseño

Facade

Propiedades:

◦Tipo: Estructural

◦Nivel: Componente

Propósito

◦Brindar una interfaz simplificada par aun grupo

de subsistemas o un sistema complejo

Page 44: Patrones de Diseño

Facade

Introducción a Facade

◦Modificar GUI

◦Problema Visual

◦No forzar a recorrer pasos de configuración

◦Asistente

◦Front-End

Page 45: Patrones de Diseño

Facade

Aplicabilidad

◦Simplificar el uso de sistemas complejos

mediante asistentes

◦Reducir acoplamiento entre clientes y

subsistemas

◦Introducir capas de “fachada” en grupos de

subsistemas

Page 46: Patrones de Diseño

Facade

Descripción

◦Sistemas altamente complejos

◦Divididos en subsistemas con grupos de clases

◦Simplificar la tarea al usuario básico brindándole

una interfaz simple

◦No pretende esconder los subsistemas

◦Usuarios avanzados acceden al subsistema

directamente

Page 47: Patrones de Diseño

Facade

Implementación

Page 48: Patrones de Diseño

Facade

Ejemplo

◦Para hacer cualquier aplicación más funcional,

podemos hacer personalizable dicha aplicación.

◦Por ejemplo, cambiar el tamaño de la fuente,

colores de pantalla, etc.

◦Ahora manipularemos configuraciones basadas

en la nacionalidad

Page 49: Patrones de Diseño

Session (Sesión)

Propiedades del Patrón◦Tipo: procesamiento◦Nivel: Arquitectura

Propósito◦Permite que los servidores de sistemas

distribuidos puedan reconocer a los clientes, permitiendo que las aplicaciones asocien es estado de los distintos clientes con la comunicación Cliente/Servidor

Page 50: Patrones de Diseño

Session (Sesión)

Aplicabilidad

◦El patrón Session es apropiado para sistemas

Cliente/Servidor, con el siguiente requisito:

Identificación del Cliente: alguna forma de

distinguir los llamadores en un sistema

multiusuario.

Page 51: Patrones de Diseño

Session (Sesión)

Aplicabilidad

◦Además se suele utilizar con alguna de las dos

características:

Funcionamiento Continuo: Asociar operaciones

específicas entre sí en un sistema. Pueden seguir un

modelo transaccional o flujo de trabajo.

Persistencia de Datos: Asociar datos con el cliente

durante el tiempo que el cliente interactúa con el

servidor.

Page 52: Patrones de Diseño

Session (Sesión)

Descripción:

◦Se divide en las siguientes secciones:

Comunicación con y sin estado.

Las aplicaciones pueden necesitar comunicación

con estado.

El patrón y la comunicación con estado.

Comunicación con estado en el mundo real

Page 53: Patrones de Diseño

Session (Sesión)

Comunicación con y sin estado.

◦Comunicación con estado: Sockets.

Peticiones secuenciales

Servidor conoce las llamadas anteriores.

Page 54: Patrones de Diseño

Session (Sesión)

Comunicación con y sin estado

◦Comunicación sin estado: Servidor no tiene en

cuenta que pasó antes.

No distingue las llamadas y ellas son autocontenidas

Toda la información es proporcionada por la llamada

Modelo sencillo de implementar

Simplifica código tanto en cliente como en servidor

Page 55: Patrones de Diseño

Session (Sesión)

Comunicación con y sin estado

◦Comunicación sin estado

Internet es un ejemplo claro

HTTP es un mecanismo de comunicación sin

estado entre un navegador y servidor

Mediante operaciones básicas permite transferir

documentos por la Web

Page 56: Patrones de Diseño

Session (Sesión)

Las Aplicaciones pueden necesitar comunicación con estado

◦Aplicaciones de Negocio necesitan soporte para:

Flujo de Trabajo: secuencia de operaciones de

negocio interrelacionadas

Transacciones: conjunto de operaciones que se

ejecutan como una unidad

Datos de Aplicación: información asociada con la

interacción cliente/servidor

Page 57: Patrones de Diseño

Session (Sesión)

Las Aplicaciones pueden necesitar comunicación con estado

◦Aplicaciones de Comercio electrónico guardan

el contenido del carro de compras mientras el

usuario está visitando el sitio.

Page 58: Patrones de Diseño

Session (Sesión)

Las Aplicaciones pueden necesitar comunicación con estado

◦La compra en línea utiliza flujos de trabajo para

definir las acciones necesarias al comprobar y

pagar la compra y entregar un pedido

◦Claramente es necesario una forma de

representar la interacción entre el cliente y el

servidor mientras dura la compra.

Page 59: Patrones de Diseño

Session (Sesión)

El patrón Session y la comunicación con estado

◦Útil para aplicaciones complejas

◦Establece identidades de múltiples clientes

◦Uno o más objetos representan el estado de la

comunicación entre Cliente y Servidor.

◦Continuidad entre ambos durante largos periodos

de tiempo

Page 60: Patrones de Diseño

Session (Sesión)

El patrón Session y la comunicación con estado

◦Soportar flujos de trabajo entre múltiples

interacciones C/S.

◦Asociar múltiples acciones en una unidad

◦Sin esto, servidor no logra registrar operaciones

de cada cliente.

Page 61: Patrones de Diseño

Session (Sesión)

El patrón Session y la comunicación con estado

◦Aplicaciones Web utilizan sesiones para esto.

◦Web: modelo sin estado

◦Para soportar comercio electrónico se necesita

gestionar una sesión.

◦Agregar/Eliminar elementos del carro

◦Sino… Formulario de compra en línea.

Page 62: Patrones de Diseño

Session (Sesión)

Comunicación son estado en el mundo real

◦En restaurant de sushi, por ejemplo, se utiliza

el reconocimiento de caras para establecer la

relación entre el cliente y el uso de los

servicios.

Page 63: Patrones de Diseño

Session (Sesión)

Comunicación son estado en el mundo real

◦Permite que el servidor (quien atiende el local)

distinga las peticiones de los clientes,

gestionando múltiples peticiones.

Page 64: Patrones de Diseño

Session (Sesión)

Comunicación son estado en el mundo real

◦Si el cliente 42 demora en comprar, pidiendo

primero dos sashimi de atún y un Temaki Crab,

luego cancelando el Temaki y cambiándolo por

un Orimushi y agregando un Makimono.

Page 65: Patrones de Diseño

Session (Sesión)

Comunicación son estado en el mundo real

◦Aunque el cliente haga varias peticiones, el

servidor sabe que el pedido final corresponde al

mismo usuario, y que nadie más tendrá el

Orimushi del cliente 42.

Page 66: Patrones de Diseño

Session (Sesión)

Comunicación son estado en el mundo real

◦El peligro del sistema es que los demás clientes

pierdan la paciencia con el 42, por lo que el

locatario debería tener más ayuda, haciendo

que el restaurant sushi sea Multithread.

Page 67: Patrones de Diseño

Session (Sesión)

Implementación

◦Identificación de sesión:

Mantener la identidad del cliente mientras viva la

aplicación.

◦Representación de la sesión:

Dependiendo de las necesidades, pueden utilizase

uno o más objetos para representar el estado.

Page 68: Patrones de Diseño

Session (Sesión)

Ventajas e Inconvenientes

◦Identificación de peticiones de Servicio

◦Mantenimiento de recursos basados en estado

◦Controlar la prioridad en el acceso a recursos de

servidor

◦Mantener información sobre estado de un

cliente durante una serie de transacciones

Page 69: Patrones de Diseño

Session (Sesión)

Ventajas e Inconvenientes

◦Sobrecarga en el servidor

◦Complejidad en el software del Servidor

◦Alguna forma de establecer identidad de

Clientes, almacenar y recuperar información.

◦Validar identidad de clientes en varias

ocasiones durante la aplicación

Page 70: Patrones de Diseño

Session (Sesión)

Page 71: Patrones de Diseño

Session (Sesión)

Ejemplo

◦El Cliente usa el servidor para actualizar datos de

contactos en un libro de direcciones compartido.

Puede ejecutar 4 operaciones:

Añadir un contacto

Añadir una dirección

Eliminar una dirección

Guardar los cambios en la dirección y el contacto