View
231
Download
0
Embed Size (px)
Citation preview
Patrones de DiseñoArquitecturas de Software
Marcelo Magaña
¿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”
¿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
¿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
¿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
¿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
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++
OOPSLA
Object-Oriented Programming, Systems, Languages & Applications
◦Conferencia anual de la ACM (Association for
Computing Machinery)
◦Orlando, Florida
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
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
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
Nivel
Clase Única
◦Aplica a una única clase
Componente
◦Grupo de Clases
Arquitectónico
◦Coordinar acciones de sistemas y subsistemas
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
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
Patrones de Creación
Introducción
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Patrones de Creación
Facilitan la tarea de Crear Objetos
Proporcionan:
◦Instanciación Genérica
◦Simplicidad
◦Restricciones de Creación
Instanciación Genérica
Crear Objetos sin identificar una clase
específica
“Generics” en Java.
Palabra reservada “instanceof”
Simplicidad
Facilitan la creación de Objetos
No es necesario escribir grandes y
complejos códigos
Restricciones de Creación
Algunos patrones fuerzan ciertas
restricciones
◦Tipo de Objetos
◦Número de Objetos
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
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
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
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
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
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
Abstract Factory
Ejemplo:◦La Interfaz AddressFactory representa la fábrica
en si misma
Abstract Factory
Abstract Factory
Abstract Factory
Abstract Factory
Abstract Factory
Abstract Factory
Abstract Factory
Abstract Factory
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
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
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.
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.
Singleton
Implementación
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”
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.
Facade
Propiedades:
◦Tipo: Estructural
◦Nivel: Componente
Propósito
◦Brindar una interfaz simplificada par aun grupo
de subsistemas o un sistema complejo
Facade
Introducción a Facade
◦Modificar GUI
◦Problema Visual
◦No forzar a recorrer pasos de configuración
◦Asistente
◦Front-End
Facade
Aplicabilidad
◦Simplificar el uso de sistemas complejos
mediante asistentes
◦Reducir acoplamiento entre clientes y
subsistemas
◦Introducir capas de “fachada” en grupos de
subsistemas
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
Facade
Implementación
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
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
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.
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.
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
Session (Sesión)
Comunicación con y sin estado.
◦Comunicación con estado: Sockets.
Peticiones secuenciales
Servidor conoce las llamadas anteriores.
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
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
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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
Session (Sesión)
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