UNIVERSIDAD NACIONAL DEL SANTA

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

PATRONES DE DISEÑO
DE SOFTWARE

Manual de Aprendizaje teórico práctico

Ms. Yim Isaias Apestegui Florentino

Nuevo Chimbote, Perú

Abril 2019
2
Acerca del autor

3
Requisitos previos
Este manual está pensado para estudiantes de la carrera de ingeniería de sistemas
e informática y afines programadores junior que se inician en la carrera como
programadores de software o para programadores senior que desean aplicar
conocimientos de patrones de diseño.

De manera que se necesita conocimientos básicos de programación orientada a

objetos y conocimientos de UML, básicamente de los diagramas de clases y de
secuencia a fin de entender mejor cada patrón.

4
1.- Introducción a los Patrones de Diseño de Software
Un patrón de diseño es una abstracción de una solución. Los patrones tratan de
solucionar problemas que existen en muchos niveles de abstracción. Los
patrones pueden estar inmersas en las distintas etapas del desarrollo; partiendo
del análisis al diseño y desde la arquitectura hasta la implementación.

Un poco de historia

Por los años 1994, se publica el libro "Design Patterns: Elements of Reusable
Object Oriented Sofware" escrito por los 4 amigos Gang of Four (GoF), que en
español es la pandilla de los cuatro, formada por Erich Gamma, Richard Helm,
Ralph Johnson y John Vlissides. Ellos recopilaron y documentaron 23 patrones
de diseño aplicados usualmente por expertos diseñadores de software orientado
a objetos.
5
Según el libro de Erich Gamma, Design Patterns: Elements of Reusable
Object-Oriented Software, un Patrón de Diseño es "una solución simple y
elegante a un problema específico y común del Diseño Orientado a Objetos
(DOO)". Indicando que: "son soluciones basadas en la experiencia y cuya
fiabilidad está demostrada".

Los patrones de diseño son la base para la búsqueda de soluciones a problemas

comunes o problemas recurrentes en el desarrollo de software y otros ámbitos
referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño.

¿Problemas de diseño? ¡Claro! Imagínese que Ud. tiene que construir un
edificio, posiblemente tendrá que preguntarse por
las características de dicho edificio: Cómo debe
apreciarse por dentro y fuera del mismo, cómo es
su estructura, qué tanto debe soportar dichas
estructuras, cómo debe interaccionar con su
entorno.

De manera similar, si Ud. construye un sistema, debe saber por dónde empezar,
qué características debe tener dicho sistema, cómo interactúa con su entorno.
Y si dicho sistema necesita software, pues
debe saber qué se espera de dicho
software, como es su comportamiento,
cómo son sus interfaces, qué problemas
soluciona dicho software, y como se
adapta a nuevos componentes, etc.

6
De manera que, en la ingeniería, siempre tendremos problemas de diseño.

De hecho, que los problemas de diseño no son nuevos; tienen precedentes,

alguien ya se enfrentó a dichos problemas y los han tipificado, estudiado y
mejorado de tal manera que se han convertido en modelos base de solución,
que lo llamaremos patrones de diseño.

Los patrones de diseño han sido optimizados, son soluciones reutilizables a los
problemas de programación. Un patrón de diseño no es una clase o una
biblioteca que, simplemente, puede conectarse a nuestro sistema, es mucho más
que eso.

Es una plantilla que tiene que aplicarse a la situación correcta. Tampoco es

específica de un lenguaje. Un buen patrón de diseño debe poder aplicarse en la
mayoría de los lenguajes de programación.

Algunos autores mencionan que, cualquier patrón de diseño puede ser un arma
de doble filo, si se aplican en el lugar equivocado, puede ser desastroso y crear
muchos problemas mayores. Sin embargo, si se implementa en el lugar correcto
y en el momento adecuado, puede ser de gran ayuda.

De manera que 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 reutilizable, lo que significa que es aplicable a diferentes
problemas de diseño en distintas circunstancias.

Objetivos de los patrones

Los patrones de diseño pretenden:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas

software.

7
 • Evitar la reiteración en la búsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores
condensando conocimiento ya existente.

Asimismo, no pretenden:

• Imponer ciertas alternativas de diseño frente a otras.

• Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener

el mismo problema o similar que soluciona el patrón, siempre teniendo en
cuenta que en un caso particular puede no ser aplicable. “Abusar o forzar el uso
de los patrones puede ser un error”.

Categorías de patrones

Según la escala o nivel de abstracción:

• Patrones de arquitectura: Aquellos que expresan un esquema

organizativo estructural fundamental para sistemas de software.
• Patrones de diseño: Aquellos que expresan esquemas para definir
estructuras de diseño (o sus relaciones) con las que construir sistemas de
software.

• Dialectos: Patrones de bajo nivel específicos para un lenguaje de

programación o entorno concreto.

Además, también es importante reseñar el concepto de “antipatrón de diseño”,

que con forma semejante a la de un patrón, intenta prevenir contra errores
8
comunes de diseño en el software. La idea de los antipatrones es dar a conocer
los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar
que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida
por haber cometido los mismos errores.

Además de los patrones ya vistos actualmente existen otros patrones como el

siguiente:

• Interacción: Son patrones que nos permiten el diseño de interfaces web.

Estructuras o plantillas de patrones

Para describir un patrón se usan plantillas más o menos estandarizadas, de

forma que se expresen uniformemente y puedan constituir efectivamente un
medio de comunicación uniforme entre diseñadores. Varios autores eminentes
en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría
definen los mismos conceptos básicos.

La plantilla más común es la utilizada precisamente por el GoF y consta de los

siguientes apartados:

• Nombre del patrón: nombre estándar del patrón por el cual será
reconocido en la comunidad (normalmente se expresan en inglés).
• Clasificación del patrón: creacional, estructural o de comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón? También
conocido como: Otros nombres de uso común para el patrón.
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
• Estructura: Diagramas de clases oportunos para describir las clases que
intervienen en el patrón.
• Participantes: Enumeración y descripción de las entidades abstractas (y
sus roles) que participan en el patrón.

9
 • Colaboraciones: Explicación de las interrelaciones que se dan entre los
participantes.
• Consecuencias: Consecuencias positivas y negativas en el diseño
derivadas de la aplicación del patrón.
• Implementación: Técnicas o comentarios oportunos de cara a la
implementación del patrón.
• Código de ejemplo: Código fuente ejemplo de implementación del
patrón.
• Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
• Patrones relacionados: Referencias cruzadas con otros patrones.

Fuentes:

https://ittgweb.wordpress.com/2016/05/29/3-2-patrones-de-diseno/

http://www.ciberaula.com/articulo/diseno_patrones_j2ee

10
Comprensión de las clases y los objetos

Objetos
Los Objetos son o representan cosas, podría decir Cosas Físicas o abstractas.

Los objetos pueden ser tan simples como por ejemplo una mesa, o tan compleja
como un motor. De manera que los objetos pueden ser reales, tangibles como
intangibles o hasta imaginarios, por ejemplo, el objeto “sentimientos” que solo
podemos caracterizar o definirlo por sus atributos tipo de sentimiento.

Así tenemos ejemplos de objetos: Una varilla de fierro, filete de pescado,

conservas de espárragos, objetos producidos en la Provincia del Santa (Perú),
así como una Red de Datos, un automóvil, una empresa, un “Hola Mundo”.

Atributos

Para nosotros serán representación de los valores o características de los

objetos, los cuales nos permite definir sus cualidades inclusive hasta su estado
(término que veremos más adelante).

Así si pensamos en un mototaxi.

11
Podemos definir que existen Características Variables, como:

• La velocidad; que varía desde el arranque

• La aceleración: que varía entre cambios de velocidades.
• Clima: sensación de la temperatura dentro del vehículo.
• Capacidad de Combustible: De acuerdo a cuánto se llena en el grifo.

Así mismo, podemos definir Características Constantes, como:

• Modelo
• Marca
• Color
• Serie de motor
• Velocidad Tope
• Capacidad máxima de pasajeros.
• Número de llantas.

Mensajes.

Los objetos, para nuestro estudio deben tener la capacidad de comunicarse por
medio de mensajes. Claro está que los mensajes deben tener el dato, o
información necesaria que el otro objeto espera. Si un objeto desea que otro
objeto realice una operación o realice algo, el primero debe enviarle un mensaje

En adelante estas operaciones a realizar se conocerán como métodos, un objeto

debe realizar un método frente a un mensaje de otro objeto.

Características de un mensaje.
• Objeto destino del mensaje enviado. laMototatxi
• Método a ejecutarse. encenderMotor
• Parámetros del método. contactoenON

Otros métodos que puede realizar laMototaxi

• Encender Motor

12
 • Apagar Motor
• Acelerar
• Frenar
• Avanzar hacia adelante
• Retroceder (sólo algunas motos).
• Girar a la derecha
• Girar a la izquierda
• Realizar cambios (tipo cambio)

Para nuestro caso Realizar Cambios (tipo cambio): “Realizar Cambios”

corresponde al nombre del Método, “tipo cambio”, pertenece a los
parámetros requeridos. En la bibliografía también a los parámetros se le
conoce como argumentos. Por ello se suele decir en programación: “… qué
tipo de argumento o tipo de parámetros se está pasando al método…”.

Los métodos suelen devolver valores de retorno generalmente, pero a veces

no devuelven valores y sólo realizan una determinada operación.

Las Clases

Representan un tipo especial o particular de una colección de objetos, que

pueden tener características similares inclusive comportamiento, pero que no
representa un concepto más general que el de un objeto.

13
Así podríamos tener una clase Mototaxis, o una clase más genérica llamada
clase automóvil o más aún una clase Vehículo. Y cada clase podría tener toda
una variedad de objetos.

Entonces hacer POO(Programación Orientada a Objetos), es escribir el

código que corresponde a cada clase con sus atributos, métodos y los mensajes
correspondientes.

Ejemplo:

Definición de una clase en Java

class vehiculo {

// atributos:
String modelo;
String marca;
String color;
double velocidad_tope;
String tipo_gasolina;
double velocidad;
double aceleracion;

// métodos:
void encender() {
// instrucciones para encender
};
void partida() {
// instrucciones para la partida del vehículo
};

void frenar() {
// instrucciones para frenar el vehículo
};

14
 void acelerar() {
// instrucciones para acelerar el vehículo
};
void girar_derecha(int grados) {
// instrucciones para girar a la derecha
};
// Así se pueden añadir otros métodos
}; // fin definición de la clase vehículo

Estado del objeto

Bien, ahora sí estamos en ya en la capacidad de entender que de cada clase

podemos crear otros objetos o múltiples objetos, donde cada objeto tiene sus
atributos con valores específicos o propios. Esa instantánea en la que los
atributos del objeto toman valores específicos se conoce como estado del
objeto.

empleado1:Empleado
NOMBRE apellido=”Zamudio”
nombre=”Danton” ESTADO INTERNO
sexo=”masculino”
sueldo=”2000.00”
calcularSueldo()
INTERFACE calcularAñosServicio()

En el ejemplo empleado1 sería un objeto que pertenece a la clase Empleado

Todos los objetos con el mismo estado interno, y las mismas interfaces se
agrupan en una sola clase.

15
La representación de los diagramas de clases en UML, es a través de un
rectángulo denominado clasificador. Un clasificador nos indica el nombre de
la clase y un ejemplo de dicha clase será un objeto. Las clases tienen
características que comprenden a los atributos y los comportamientos
(métodos).

Cuando empiece a captar clases en sus modelos, abstraiga

de modo conceptual como una fase inicial, basta empezar
solamente con clases y relaciones. Las características se
agregan más adelante (Kimmel, 2008).

Relaciones entre clases

Como paradigma las clases se construyen para que trabajen de manera
relacionada, compartiendo atributos y métodos y sobre todo, evitando la
reescritura de código.

Precisamente las jerarquías entre clases permiten extender y reutilizar código,

así tenemos:

• R1:Herencia (Generalización / Especialización o Es-un)

• R2:Agregación (Todo / Parte o Forma-parte-de)
• R3:Composición (Es parte elemental de)
• R4:Asociación (entre otras, la relación Usa-a)

16
R1: Relación de Herencia (Generalización / Especialización o Es-
un)

Es un tipo de jerarquía de clases, donde cada subclase contiene los atributos y

métodos de una (herencia simple) o más superclases (herencia múltiple).

Vehiculo.java Automovil.java Camion.java

package model; package model; package model;

public class Vehiculo public class public class Camion

{ Automovil extends extends Vehiculo
Vehiculo {
{
public Vehiculo(){ public Automovil(){ public Camion(){
super(); super(); super();
} } }

} } }

17
R2:Relación de Agregación (Todo / Parte, Forma parte de)

Este tipo de relación representa a los objetos compuestos por otros objetos.

El objeto en el nivel superior de la jerarquía es el todo y los que están en los

niveles inferiores son sus partes o componentes.

Vehiculo.java Motor.java
package model; package model;

public class Vehiculo public class Motor

{ {

public Vehiculo vehiculo;

public Motor motor;

public Motor(){
public Vehiculo(){ super();
super(); }
}
}
}

18
R3:Relación de Composición

Un componente es parte esencial de un elemento. Si el componente es

eliminado o desaparece, la clase mayor deja de existir.

Persona.java Cabeza.java

package model; package model;

import java.util.HashSet;
import java.util.Set;
public class Persona
{
public class Cabeza
{
public Cabeza cabeza;
public Set<Persona> persona;

public Persona(){ public Cabeza(){

super(); super();
} }

} }

19
R4: Relación de Asociación («uso», usa, cualquier otra relación)

La relación de asociación se establece cuando dos clases tienen una

dependencia de uso es decir, una clase usa atributos y/o métodos de otra para
funcionar.

Cliente.java Compra.java

package model; package model;

import java.util.HashSet;
import java.util.Set;
public class Compra
{
public class Cliente
{ public Cliente cliente;

public Set<Compra> compra;

public Compra(){
super();
public Cliente(){ }
super();
} }

20
Encapsulamiento

Los objetos muestran hacia afuera la interface, pero ocultan la implementación

y el estado interno.

Existen tres niveles de acceso para el encapsulamiento, los cuales son:

Público (Public): Todos pueden acceder a los datos o métodos de una clase
que se definen con este nivel, este es el nivel más bajo, esto es lo que deseamos:
que la parte externa vea.

Protegido (Protected): Podemos decir que no son de acceso público,

solamente son accesibles dentro de su clase y por subclases.

Privado (Private): En este nivel se puede declarar miembros accesibles sólo

para la propia clase.

Vamos a ver un ejemplo:

El Ejemplo del Vehículo nuevamente, donde se tiene la característica COLOR.

CASO 1: Se necesita que cualquiera pueda acceder al color de un vehículo,

entonces:

Opción a: Declaro entonces COLOR como Privado

Opción b: Declaro entonces COLOR como Protegido

Opción c: Declaro entonces COLOR Como Público

CASO 2: Se necesita qué color se pueda acceder a través no sólo de vehículo, sí

no ahora también a través de Camión (que es un tipo de vehículo), entonces
también se debe tener acceso a color.

Opción a: Declaro entonces COLOR como Privado

Opción b: Declaro entonces COLOR como Protegido

Opción c: Declaro entonces COLOR Como Público

21
CASO 3: Se requiere acceder a color, solamente para vehículo.

Opción a: Declaro entonces COLOR como Privado

Opción b: Declaro entonces COLOR como Protegido

Opción c: Declaro entonces COLOR Como Público

22
Ejercicios
1.-Diseñe objetos:

a).-Defina el nombre del objeto, b) Establezca cinco atributos y c) Defina 2

métodos para los siguientes objetos: rectángulo, círculo, silla, mesa,
refrigerador, ventilador, televisor, casa, aula, plancha, puerta, ventana, camión,
bicicleta, barco, grifo, taza, amor, miedo, paciencia, carta pájaro, oveja, perro,
abeja, libro, cuchara, billete, nieve, azúcar, leche, pan, rosa, flor, queso,
panadero, abrelatas, sacapuntas, limpiavidrios, venta, compra, contrato,
matricula, recibo, motor. Diseñe 2 estados internos para cada objeto.

2.- Interprete los siguientes diseños siguiente diseño, distinga qué tipo de
relación corresponde y codifique en java.

a)

b)

23
 c)

4.- Diseñar el modelo siguiente:

a) Cada aula alberga uno o más grupos a los que se imparten una o más
asignaturas, a su vez cada grupo tiene asignada una o más aulas en donde recibe
docencia de una o más asignaturas, y además cada asignatura se imparte en una
o más aulas a uno o más grupos.

b) Diseñar un diagrama de clases que modele el proceso de dar de alta a cada

una de las personas que se apuntan a una asociación. De cada persona interesa
saber sus datos básicos: RUC, nombre completo y fecha de nacimiento. Cuando
cada nuevo socio se da de alta, se le asigna un código de asociado alfanumérico
y se anota la fecha de alta. La clase Fecha se modela con tres campos (día, mes
y año) de tipo entero. La clase RUC se modela con un campo de tipo entero
llamado dni y un campo de tipo carácter llamado letra.

c) Diseñar un diagrama de clases que modele la estructura necesaria para

manejar los datos de los encuentros de un torneo de tenis de mesa en la
modalidad de sorteo y eliminatoria.

24
Del torneo interesa conocer la fecha del torneo, los encuentros celebrados y el
ganador. De cada jugador, que debe de conocer perfectamente las reglas,
interesa saber el número de federado de la federación de la que es miembro.

De cada persona interesa saber sus datos básicos: RUC, nombre completo y
fecha de nacimiento. La clase Fecha se modela con tres campos (día, mes y
año) de tipo entero. La clase RUC se modela con un campo de tipo entero
llamado dni y un campo de tipo carácter llamado letra.

De cada encuentro interesa conocer los oponentes, el ganador y el resultado

final del marcador de cada una de las tres partidas que se juegan a 21 puntos.

https://slideplayer.es/slide/3965899/
https://styde.net/encapsulamiento-en-la-programacion-orientada-a-objetos/

25
El Patrón Abstract Factory (
El objetivo del patrón Abstract Factory es la creación de objetos agrupados en
familias sin tener que conocer las clases concretas destinadas a la creación de
estos objetos.

Ejemplo de un Sistema de Venta de Vehículos

Venta de vehículos, tomado de (Debrauwer, 2013).

El sistema de venta de vehículos gestiona vehículos que funcionan con gasolina

y vehículos eléctricos. Esta gestión está delegada en el objeto Catálogo
encargado de crear tales objetos.

Para cada producto, disponemos de una clase abstracta, de una subclase

concreta derivando una versión del producto que funciona con gasolina y de
una subclase concreta derivando una versión del producto que funciona con
electricidad.

26
Para el objeto Scooter, existe una clase abstracta Scooter y dos
subclases concretas ScooterElectricidad y ScooterGasolina.

El objeto Catálogo puede utilizar estas subclases concretas para instanciar los
productos.
No obstante si fuera necesario incluir nuevas clases de familias de vehículos
(diésel o mixto gasolina-eléctrico), las modificaciones a realizar en el objeto
Catálogo pueden ser bastante pesadas.

SOLUCIÓN
El patrón Abstract Factory resuelve este problema introduciendo una interfaz
FábricaVehículo que contiene la firma de los métodos para definir cada
producto. El tipo devuelto por estos métodos está constituido por una de las
clases abstractas del producto. De este modo el objeto Catálogo no necesita
conocer las subclases concretas y permanece desacoplado de las familias de
producto. Se incluye una subclase de implementación de FábricaVehículo por
cada familia de producto, a saber las subclases FábricaVehículoElectricidad y
FábricaVehículoGasolina. Dicha subclase implementa las operaciones de
creación del vehículo apropiado para la familia a la que está asociada.
El objeto Catálogo recibe como parámetro una instancia que responde a la
interfaz FábricaVehículo, es decir o bien una instancia de
FábricaVehículoElectricidad, o bien una instancia de
FábricaVehículoGasolina. Con dicha instancia, el catálogo puede crear
y manipular los vehículos sin tener que conocer las familias de vehículos y las
clases concretas de instanciación correspondientes.

27