Nombre de la Universidad Universidad Estatal de Milagro

Carrera Ingeniería de Software Nivel 3

Nombre de la Asignatura Modelamiento de Software

Integrantes

Tema del Trabajo Practica Experimental

Nombre del Docente Mariuxi Geovanna Vinueza Morales

Fecha de Entrega 11/03/2022

 Patrón Factory

El patrón de diseño Abstract Factory busca agrupar un conjunto de clases que

tiene un funcionamiento en común, llamadas familias, las cuales son creadas
mediante un Factory. Este patrón es especialmente útil cuando requerimos
tener ciertas familias de clases para resolver un problema, sin embargo, puede
que se requieran crear implementaciones paralelas de estas clases para
resolver el mismo problema, pero con una implementación distinta.

Se le conoce como familia a un conjunto de clases que buscan resolver la

misma problemática, por ejemplo, los drivers de JDBC, todas estas clases
implementan las interfaces estándares de Java; sin embargo, cada driver  
tiene implementaciones distintas para conectarse a una base de datos
específica

El patrón de diseño  Abstract Factory  se puede llegar a confundir con el patrón

Factory Method, la diferencia entre ambos es que Abstract Factory  se enfoca
en la creación de familias completas de objetos y el Factory Method  se enfoca
en la creación individual de objetos.
La estructura de  Abstract Factory puede resultar muy enredosa ya que tiene 
muchos componentes y éstos aparentemente se mezclan entre sí. Para
comprender mejor cómo funciona este patrón explicaremos cada componente.

 Client: Representa la persona o evento que dispara la ejecución del

patrón.
 AbstractProduct (A, B): Interfaces que definen la estructura de los
objetos de cada familia.
 ConcreteProduct (A, B): Clases que heredan de AbstractProduct con el
fin de implementar familias de objetos concretos.
 ConcreteFactory: Representan las fábricas concretas que servirán para
crear las instancias de todas las clases de la familia. En esta clase debe
existir un método para crear cada una de las clases de la familia.
 AbstractFactory: Define la estructura de las fábricas y deben
proporcionar un método para cada clase de la familia.

Cuando utilizarlo:

 Cuando la creación directa de un objeto por medio del operador del

operador new puede ser perjudicial.
 Cuando no se conoce el tiempo de diseño, la familia de familia de clases
que clases que se utilizará en ejecución.
 Cuando es necesario controlar la creación de objetos por medio de una
interface común.
 Cuando es necesario trabajar con distintas plataformas, manteniendo la
misma estructura y compatibilidad con todas ellas.

Patrón Factory Method

Factory Method permite la creación de objetos de un subtipo determinado a

través a través de una clase Factory. Esto es especialmente útil cuando no
sabemos, en tiempo de diseño, el subtipo que vamos a utilizar o cuando
queremos delegar la lógica de creación de los objetos a una clase Factory.
Utilizando este patrón podemos crear instancias dinámicamente mediante la
configuración, estableciendo cual será la implementación a utilizar en un
archivo de texto, XML, properties o mediante cualquier otra estrategia.

Los componentes que conforman el patrón son los siguientes:

 IProduct: Representa de forma abstracta el objeto que queremos crear,

mediante esta interface se definen la estructura que tendrá el objeto
creado.  
 ConcreteProduct: Representa una implementación concreta de la
interface IProduct, la cual es creada a través del ConcreteFactory.
 AbstractFactory: Este componente puede ser opcional, sin embargo,
se recomienda la creación de un AbstractFactory  que define el
comportamiento por default de los ConcreteFactory.
 Concrete Factory: Representa una fábrica concreta la cual es utilizada
para la creación de los ConcreteProduct, esta clase hereda el
comportamiento básico del AbstractFactory.
Cuando utilizarlo:

 Cuando la creación directa de un objeto por medio del operador del

operador new puede ser perjudicial.
 Cuando no se conoce el tiempo de diseño, la subclase que se utilizará.
 Cuando es necesario controlar la creación de objetos por medio de una
interface común.
 Cuando construimos un objeto basado en una serie de condiciones else
if  else  o switch.

Patrón Builder

Este es un patrón bastante simple, pero muy útil, que permite crear objetos
complejos a través de uno más simple. Es muy común encontrarnos con
situaciones en las cuales tenemos que crear objetos manual y repetidas veces,
lo que manual y repetidas veces, lo que nos lleva a tener compuestos de forma
nos lleva a tener que establecer cada propiedad que establecer cada propiedad
del objeto, y si este, además tiene objetos compuestos dentro, tendremos que
crearlos primero para después ser asignados al objeto que estamos
construyendo. Esto desde luego que se construyendo. Esto desde luego que se
hace una tare hace una tarea tediosa y cansada, sobre a tediosa y cansada,
sobre todo cuando tenemos que crear objetos de manera frecuente.

Los componentes que conforman el patrón son los siguientes:

  IBuilder: Este componente no es obligatorio en todos los casos, sin
embargo, es buena práctica especificar una interface que tendrán en
común todos los Builder  que definiremos en nuestra aplicación, puede
ser una interface que defina únicamente el método build.
 ObjectBuilder: Esta es la clase que utilizaremos para crear los
TarjetObjet. Esta clase debe de heredar de IBuilder e implementar el
método build, el cual será utilizado para crear al TarjetObject. Como
regla general todos los métodos de esta clase retornan general todos los
métodos de esta clase retornan una instancia de sí a instancia de sí
mismo, con la finalidad de agilizar la creación. Esta clase por lo general
es creada como una clase interna del TargetObject.
 TarjetObjet: Representa el objeto que deseamos crear con ayuda del
ObjectBuilder, ésta puede ser una clase simple o puede ser una clase
muy compleja que tenga dentro más objetos.
 OtherObjets: Representa los posibles objetos que deberán ser creados
cuando el TarjetObject  sea construido por el ObjectBuilder.

Utilizarlo cuando:

 Cuando necesitamos un mecanismo simple para crear objetos

complejos.
 Cuando necesitamos crear repetidamente objetos complejos.
 Cuando necesitamos ocultar a los usuarios la complejidad de la creación
de un objeto determinado.

Patrón Decorator

El patrón decorator está diseñado para solucionar problemas donde la jerarquía

con subclasificación no puede ser aplicada, o se requiere de un gran impacto
en todas las clases de la jerarquía con el fin de poder lograr el comportamiento
esperado. Decorator  permite al usuario  permite al usuario añadir nuevas
funcionalidades a añadir nuevas funcionalidades a un objeto un objeto
existente sin alterar su estructura, mediante la adición de nuevas clases que
envuelven a la anterior dándole funcionamiento extra.
Este patrón está diseñado con la finalidad de que múltiples decoradores
puedan ser apilados uno encima del otro agregando funcionalidad por cada
decorador que es añadido a la estructura.

En la imagen podemos apreciar los distintos componentes que conforman el

patrón de diseño Decorator los cuales se explican a continuación:

 IComponent: Interface que define la estructura minina del componente

o componentes que pueden ser decorados.
 ConcreteComponent: Implementación de IComponent  y define un  y
define un objeto concreto que puede ser decorado.
 ComponentDecorator: Por lo general es una clase abstracta  que
define que define la estructura mínima de un Decorador, el cual
mínimamente deben de heredar de IComponent  y contener alguna
subclase de IComponent  al cual decorarán.
 ComponentDecoratorImpl: Representan todos los decoradores
concretos que heredan de ComponentDecorator.
 Cuando utilizarlo:

 Cuando necesitamos agregar dinámicamente una nueva

funcionalidad sobre un objeto y esta funcionalidad se agrega sobre
capas de funcionalidad previas.
 Cuando implementar una nueva funcionalidad mediante la herencia
es muy complicado o se requieren de fuertes cambios para
implementarlos.

Patrón Facade

El patrón Facade (fachada) tiene la característica de ocultar la complejidad de

interactuar con un conjunto de subsistemas proporcionando una interface de
alto nivel, la cual se encarga de realizar la comunicación con todos los
subsistemas necesarios.

La fachada es una buena estrategia cuando requerimos interactuar con varios

subsistemas para realizar una operación concreta ya que se necesita tener el
conocimiento técnico y funcional para saber qué operaciones de cada
subsistema tenemos que ejecutar y en qué orden, lo que puede resultar muy
complicado cuando los sistemas empiezan a crecer demasiado.
En la imagen podemos apreciar los componentes que integran el patrón
Facade, los cuales se explican a continuación:  

 IFacade: Proporciona una interface de alto nivel Proporciona una

interface de alto nivel que oculta que oculta la complejidad de interactuar
con varios sistemas para realizar una operación.
 Client: Sistema o evento que i Sistema o evento que interactúa con la
fachada. nteractúa con la fachada.
 DefaultFacadeImpl: Representa la implementación de IFacade y se
encarga de comunicarse con todos los subsistemas.
 Subsystems: Representa módulos o subsistemas que exponen
interfaces para comunicarse con ellos.

Cuando utilizarlo:

 Cuando interactuar con un conjunto de subsistemas es complicado,

debido a que es necesario conocer los objetos necesarios para tener
una interacción recíproca con cada sistema.
  Cuando queremos construir interfaces de alto nivel para nuestros para
usuarios.

Patron Strategy

Define una familia de algoritmos, encapsula cada uno de ellos y los hace
intercambiables. Permite que un algoritmo varié independientemente de los
clientes que lo usan.

Muchas clases relacionadas difieren solo en su comportamiento. Las

estrategias permiten configurar una clase con un determinado comportamiento
entre muchos posibles.

Se necesitan distintas variantes de un algoritmo.

Un algoritmo usa daos que los clientes no deberían conocer. Use el patón
Strategy para evitar exponer estructuras de datos complejas y dependientes del
algoritmo

Una clase define muchos comportamientos y estos se representan como

múltiples sentencias condicionales en sus operaciones. En vez de tener
muchos condicionales, podemos mover las ramas de estos a sus propias
clases estrategia

 Estrategia (Componedor)
 o Declara la interfaz común a todos los algoritmos permitidos.
o El *contexto* usa esa interfaz para llamar al algoritmo definido por
una estrategia
 Estrategia Concreta
o Implementa el algoritmo concreto
 Contexto
o Instancia un objeto Estrategia Concreta
o Mantiene una referencia a un objeto estrategia (concreta)
o Puede definir una interfaz que permita a la Estrategia (concreta)
acceder a sus datos

Template Method

El patrón de diseño templete centra su funcionalidad en la reutilización de

código y se utiliza para implementar algoritmos que realizan los mismos pasos
para llegar a una solución. Esto se logra implementando clases bases que
definan un comportamiento predeterminado. Usualmente es creado un método
para cada paso del algoritmo a implementar, de los cuales algunos serán
implementados y otros permanecerán abstractos hasta su ejecución por parte
de las subclases.
Los componentes del patrón Templete Method se explica a continuación:

 Client: Es el componente que acciona la ejecución del templete.

 AbstractTemplete: Clase abstracta con una serie de operaciones que
definen los pasos para llevar a cabo la ejecución del algoritmo. La clase
tiene el método templeteMethod que ejecuta en orden los métodos
step1, step2, step3.
 Implementation: Clase que representa un temple concreto, para lo cual
deberá de heredar de AbstractTemplete e implementar los métodos de
ésta.

Bibliografía

(PDF) Introduccion a los patrones de diseño | Gustavo Pinzon - Academia.edu.

(n.d.). Retrieved March 11, 2022, from
https://www.academia.edu/39945137/Introduccion_a_los_patrones_de_dis
eño
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Pattern
Catalog. Design, 395.
http://www.cs.up.ac.za/cs/aboake/sws780/references/patternstoarchitectur
e/Gamma-DesignPatternsIntro.pdf
Giraldo G, G. L., Acevedo O, J. F., Sc, M., & Moreno N, D. A. (n.d.). Una
ontología para la representación de conceptos de diseño de software An
ontology for the representation of software design concepts. Revista
Avances En Sistemas e Informática, 8(3).
Homsi, A. F. (2021). Desarrollo de una herramienta para el aprendizaje de
patrones de diseño software.

((PDF) Introduccion a Los Patrones de Diseño | Gustavo Pinzon -

Academia.Edu, n.d.; Gamma et al., 1994; Giraldo G et al., n.d.; Homsi, 2021)