Uso de patrones de
arquitectura
Profesor Pedro Veloso Hernández
Master Ingeniería de Software
¿ que es un Patrón de diseño?
Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño es una solución a un problema de diseño.
Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su
efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Los escaladores usan a menudo patrones de diseño, usado Arneses, cuerdas, mosquetones, que usan dadas ciertas Condiciones de soporte, forma, y para situaciones que deben Resolver como : salvataje, cruzar dos personas en un solo Intento, saltarse una gran roca, etc.
Fuente Wikipedia
"Each pattern describes a problem which occurs over
and over again in our environment, and then describes the core
of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" [AIS+77].
¿ que es un patrón UML?
Los patrones UML son colaboraciones parametrizadas
, esto es , son un grupo de clases/objetos
colaborando entre sí que se pueden abstraer de un
conjunto de escenarios general.
Los patrones son un medio excelente para lograr
reutilización y desarrollo robusto.
A medida que los patrones se descubren en todo
Condiciones para usar un patrón
UML
Los patrones generalmente describen cómo
resolver un problema abstracto y la tarea
del usuario del patrón consiste en modificar
los elementos del patrón para cumplir las
demandas del compromiso actual.
Antes de comenzar a usar un patrón
primero debe ser creado como un diagrama
estándar de UML o existir como tal en
Vamos a un ejemplo
Cuando “ no” usar patrones de
diseño
Del mismo modo que no es aconsejable optimizar
prematuramente, no se deben utilizar patrones de
diseño antes de tiempo.
Seguramente sea mejor implementar algo primero y
asegurarse de que funciona
, para luego utilizar el
patrón de diseño para mejorar las flaquezas; esto es
cierto, sobre todo, cuando aún no ha identificado
todos los detalles del proyecto ( comprensión del
dominio del problema)
Los patrones de diseño pueden incrementar o
¿ que familias de patrones de
diseño utilizaremos?
Para este curso, usaremos dos familias
de patrones de diseño propuestos en la
bibliografía sugerida. Cabe destacar que
existen muchas familias de patrones de
diseño, por lo que nos basaremos en los
mas usados, en función del objetivo que
nos hemos planteado en este curso.
Descripción de familias de patrones
GRASP :
son patrones generales de
software para asignación de
responsabilidades, es el acrónimo de
"General Responsibility Assignment
Software Patterns" .
son una serie de "buenas prácticas" de
aplicación recomendable en el diseño de
software.
Descripción de familias de
patrones
GOF:
Es la abreviación del grupo Gang of
Four, compuesto por Erich Gamma, Richard
Helm, Ralph Jhonson y John Vlisides,
quienes en su publicación “ Design
Patterns” ( década de los 90s), describen
23 patrones de diseño comúnmente
utilizados y de gran aplicabilidad en
problemas de diseño usando modelamiento
UML.
Relación de familias de patrones de
diseño
PATRONES
GOF
GRASP
Experto
Creador
Bajo acoplamientoAlta Cohesión
Controlador
Creacionales
Estructurales
ComportamientoFabrica, constructor, método de fabricación, prototipo ,
instancia única
Adaptador, puente, objeto Compuesto, envoltorio, fachada,
Peso ligero, proxy Cadena responsabilidad, orden, Intérprete, iterador, mediador, recuerdo,
Experto
El GRASP de experto en información es el
principio básico de asignación de
responsabilidades en diseño O.O.
Nos indica que la responsabilidad de la
creación de un objeto debe recaer sobre la
clase que conoce toda la información
necesaria para crearlo.
Nótese, que el cumplimiento de una
responsabilidad requiere a menudo
Ejemplo del patrón experto
Ejemplo
En la aplicación del punto de venta, alguna clase necesita conocer el gran total de la venta. Comience asignando las responsabilidades con una definición clara de ellas. A partir de esta recomendación se plantea la pregunta:
¿Quién es el responsable de conocer el gran total de la venta?
Desde el punto de vista del patrón Experto, deberíamos buscar la clase De objetos que posee la información necesaria para calcular el total.
En conclusión, para cumplir con la responsabilidad de conocer y dar el total de la venta, se asignaron tres responsabilidades a las tres clases
de objeto así:
Venta ( conoce total de la venta)
Ventaslineaproductos ( conoce subtotal de la linea de productos)
Creador
El patrón creador nos ayuda a identificar quién
debe ser el responsable de la creación (o
instanciación) de nuevos objetos o clases.
El patrón Creador guía la asignación de
responsabilidades relacionadas con la creación de
objetos, tarea muy frecuente en los sistemas
orientados a objetos.
El propósito fundamental de este patrón es
encontrar un creador que debemos conectar con el
objeto producido en cualquier evento.
Ejemplo patrón creador
Ejemplo
En la aplicación del punto de venta, ¿quién Debería encargarse de crear una Instancia VentasLineadeProducto?
Desde el punto de vista del patrón Creador, deberíamos buscar una clase que agregue, contenga y realice otras operaciones sobre este tipo de instancias
Una Venta contiene (en realidad, agrega) muchos objetos VentasLineadeProducto; por ello, el patrón Creador sugiere que
Venta es idónea para asumir la
responsabilidad de crear las instancias VentasLineadeProducto.
Bajo acoplamiento
Es la idea de tener las clases lo menos ligadas entre
sí que se pueda. De tal forma que en caso de
producirse una modificación en alguna de ellas, se
tenga la mínima repercusión posible en el resto de
clases, potenciando la reutilización, y disminuyendo
la dependencia entre las clases
Ejemplo bajo acoplamiento
Ejemplo: En el caso del punto de Ventas se tienen tres clases
Pago, TPDV y Venta y se quiere crear una instancia de Pago y asociarla a Venta.
¿Que clase es la responsable de realizarlo?
Según el patrón de Bajo
Acoplamiento la relación debería ser a través de TPDV.
Esta última asociación es mejor Dado que Venta realiza la
Alta Cohesión
Nos dice que la información que almacena una
clase debe de ser coherente y está en la
mayor medida de lo posible relacionada con la
clase.
La cohesión es una medida de cuán
relacionadas y enfocadas están las
responsabilidades de una clase.
Una clase con alta cohesión, compartirá la
responsabilidad de una operación, con otras
clases
Una clase con baja cohesión, concentrará las
responsabilidades de una o muchas
Ejemplo alta cohesión
Ejemplo: En el caso
del punto de ventas
se tienen tres clases
Pago, TPDV y Venta y
se quiere crear una
instancia de Pago y
asociarla a Venta.
Este diseño delega a Venta la responsabilidad de crear el pago.
Este diseño es conveniente ya que da soporte a una alta cohesión y a
un bajo acoplamiento.
¿Qué pasa si el sistema tiene 50 operaciones, todas recibidas por la clase TPDV ?
Controlador
El patrón controlador es un patrón que sirve como
intermediario entre una determinada interfaz y el
algoritmo que la implementa, de tal forma que es la
que recibe los datos del usuario y la que los envía a
las distintas clases según el método llamado.
Este patrón sugiere que la lógica de negocios debe
estar separada de la capa de presentación, esto para
aumentar la reutilización de código y a la vez tener un
mayor control.
Ejemplo de controlador
Por ejemplo, cuando un
cajero que usa un sistema
de Terminal en el punto
de venta oprime el botón
"Terminar Venta”, está
generando un evento
sistémico que indica que
“la venta ha terminado
Nótese que la clase TPDVApplet - parte de la capade presentación - transmite un mensaje introducirProducto al objeto TPDV.
Creacionales
1.-Fabrica abstracta (Abstract Factory) : Proporciona un interfaz para crear las familias de objetos relacionados o dependientes sin especificar sus clases concretas.
2.-Constructor (Builder): Separa la construcción de un objeto complejo de su representación , de modo que el mismo proceso de construcción pueda crear representaciones diferentes.
3.-Método fabricación(Factory Method) : Define un interfaz para crear un objeto, pero dejar a subclases decidir sus instancias . El Método De la fábrica deja a una clase la creación de ejemplares o copias a subclases.
4.-Prototipo(Prototype) : Crea nuevos objetos creándolos de una instancia ya existente.
Estructurales
6.-Adaptador (adapter) :Convierte la interfaz de una clase en otra interfaz que otra clase puede usar . debido a que la interfaces es incompatibles con dicha clase
7.-Puente ( bridge) :Desacopla una abstracción de su implementación de modo que los dos puedan variar por separado.
8.-Peso ligero (Flyweight ) :Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
9.-Fachada (Facade) : Proporciona un interfaz unificada a un juego de interfaces en un subsistema. La fachada define un interfaz de nivel más alto que hace el subsistema fácil de usar.
10.-Envoltorio (Decorator) :Adjunta responsabilidades adicionales a un objeto dinámicamente. Los decoradores proporcionan una alternativa
flexible a la subclasificación para ampliar la funcionalidad.
11.-Objeto compuesto (Composite) :El objeto compuesto permite tratar a jerarquías de objetos en individuales y composiciones de objetos uniformemente como si se tratase de objetos simples
Comportamiento
13.-Cadena responsabilidad (Chain of Responsibility ): Encadena los objetos de encubrimiento y pasa la petición a lo largo de la cadena hasta que un objeto la maneja. Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
14.-Orden (Command) : Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
15.-Intérprete (Interpreter) :Considerando un lenguaje , define un
representación para su gramática con un intérprete que usa la representación para interpretar sentencias en el mismo lenguaje.
16.-Iterador (Iterator) :Proporciona un modo de tener acceso a los elementos de un objeto agregado secuencialmente sin exponer su representación subyacente.
17.-Mediador (Mediator) :Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
Comportamiento
19.-Observador (Observer) : Define de uno a varios la dependencia entre objetos de modo que cuando se produce un cambio de estado del objeto, todos sus dependientes sean
notificados y puestos al día automáticamente.
20-Estado (State) :Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno
21.-estrategia (Strategy) : Define una familia de algoritmos ( métodos ), encapsula cada uno, y los hace permutables. La
estrategia deja al algoritmo ( método ) variar por separado de los clientes ( objetos ) que lo usan o invocan .
22.-método plantilla ( template method) :Define el esqueleto de un algoritmo en una operación, aplazando algunos pasos a
subclases. El Método de Plantilla deja a subclases redefinir los ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo.
