Clasificación de patrones de diseño

Los patrones de diseño se hicieron famosos en el libro “la banda de los

cuatro”, posteriormente pasaron a describirse en otros libros de diseño
como “The Design Patterns Smalltalk” originándose así el campo de la
arquitectura. Cabe mencionar al autor Christopher Alexander como uno
de los más destacados en este tema.Los patrones de diseño se han
dividido en al menos tres categorías:
● Patrones de creación.
● Patrones estructurales.
● Patrones de comportamiento.
(Jesús Ramírez Guerrero, 2014,
https://jesusramirezguerrero.com/2014/08/26/patrones-de-diseno-en-
java/)

En esta lectura profundizaremos en los detalles de estas categorías para luego en el

siguiente módulo profundizar sobre patrones específicos y aprender en qué
momentos nos conviene utilizarlos.

Clasi cación de patrones de diseño

Implementar una solución con el patrón estructural bridge

Referencias
Revisión del módulo
Lección 1 de 4

Clasificación de patrones de diseño

Patrones de diseño creacional

“Tienen que ver con los mecanismos de creación de objetos, tratando de

crear objetos de una manera adecuada a la situación” (Jesús Ramírez
Guerrero, 2014, https://jesusramirezguerrero.com/2014/08/26/patrones-de-
diseno-en-java/).

Patrones de diseño estructural

“Explican cómo ensamblar objetos y clases en estructuras más grandes, a la

vez que se mantiene la flexibilidad y eficiencia de estas estructuras”
(Refactoring.Guru, s.f., https://refactoring.guru/es/design-
patterns/classification). Permite la colaboración entre objetos con interfaces
incompatibles.

Patrones de diseño de tipo comportamiento

 Tratan a los objetos que manejan tipos particulares de acciones
dentro de un programa. Éstos encapsulan procesos que deben
ejecutarse dentro de la funcionalidad de la aplicación, como
interpretar un lenguaje, completar una petición, moverse a
través de una secuencia o implementar un algoritmo. (Junta de
Andalucía, s.f.,
http://www.juntadeandalucia.es/servicios/madeja/contenido/re
curso/13)

Tabla 1: Clasificación de patrones de diseño

Propósito

Ámbito Patrones de
Patrones de Patrones
comportamien
creación estructurales
to

Interpreter
Factory Adapter .
Clase method. (de clase). Template
Method.

Objeto
Abstract Adapter Chain of
 factory. (de Responsibi
objetos). lity.
Builder.
Bridge. Command.
Prototype.
Composite Iterator.
Singleton. .
Mediator.
Decorator.
Memento.
Facade.
Observer.
Flyweight.
State.
Proxy.
Strategy.
Visitor.

Fuente: elaboración propia.

Nos explayaremos sobre las características de los patrones de diseño más

importantes en los siguientes módulos, pero para comprender un poco mejor
lo que estuvimos aprendiendo hasta el momento, veremos un ejemplo de
aplicación sobre una situación concreta en Java.

C O NT I NU A R
Lección 2 de 4

Implementar una solución con el patrón estructural

bridge

Figura 1: Bridge

Fuente: Refactoring.Guru. (s. f.). Bridge. Recuperado de https://refactoring.guru/es/design-

patterns/bridge.
Para entender en qué casos nos sirve y cómo implementar el patrón bridge,
situémonos en la siguiente problemática:

Digamos que tenemos una clase geometría “forma” que a su vez tiene dos
subclases: “círculo y cuadrado”, y queremos extender esta jerarquía de
clases para que incorpore colores. Entonces lo natural es crear las subclases
de forma “rojo” y “azul”. Ahora bien, como ya tenemos dos subclases,
tenemos que crear cuatro combinaciones de clase, como círculo azul y
cuadrado rojo.

Figura 2: Problema

Fuente: Refactoring.Guru. (s. f.). Problema. Recuperado de https://refactoring.guru/es/design-

patterns/bridge.
Entonces si quisiéramos seguir agregando formas o colores, nuestra
jerarquía terminaría creciendo exponencialmente.

Pero, este problema se presenta porque intentamos extender las clases de

forma en dos dimensiones independientes: por forma y por color, y este
resulta ser un problema muy habitual en la herencia de clases.

El patrón bridge  intenta resolver este problema pasando de la

herencia a la composición del objeto. Esto quiere decir que se
extrae una de las dimensiones a una jerarquía de clases
separada, de modo que las clases originales referencian un
objeto de la nueva jerarquía, en lugar de tener todo su estado y
sus funcionalidades dentro de una clase. (Refactoring.Guru, s. f.,
https://refactoring.guru/es/design-patterns/bridge)

Figura 3: Solución
 Fuente: Refactoring.Guru. (s. f.). Solución. Recuperado de https://refactoring.guru/es/design-
patterns/bridge.

Con esta solución, podemos extraer el código relacionado con el

color y colocarlo dentro de su propia clase, con dos subclases:
rojo y azul. La clase Forma obtiene entonces un campo de
referencia que apunta a uno de los objetos de color. Ahora la
forma puede delegar cualquier trabajo relacionado con el color al
objeto de color vinculado. Esa referencia actuará como un
puente entre las clases Forma y Color. En adelante, añadir
nuevos colores no exigirá cambiar la jerarquía de forma y
viceversa. (Refactoring.Guru, s. f.,
https://refactoring.guru/es/design-patterns/bridge)

Analicemos un poco el esquema del patrón bridge.

Figura 4: Estructura

Fuente: Refactoring.Guru. (s. f.). Estructura. Recuperado de https://refactoring.guru/es/design-

patterns/bridge.

Veamos cada una de las partes que la compone:

1. La abstracción ofrece lógica de control de alto nivel. Depende

de que el objeto de la implementación haga el trabajo de bajo
nivel.
 2. La implementación  declara la interfaz común a todas las
implementaciones concretas. Una abstracción solo se puede
comunicar con un objeto de implementación a través de los
métodos que se declaren aquí.
La abstracción puede enumerar los mismos métodos que la
implementación, pero normalmente la abstracción declara
funcionalidades complejas que dependen de una amplia
variedad de operaciones primitivas declaradas por la
implementación.

3. Las implementaciones concretas contienen código específico

de plataforma.

4. Las abstracciones refinadas proporcionan variantes de lógica

de control. Como sus padres, trabajan con distintas
implementaciones a través de la interfaz general de
implementación.

5. Normalmente, el cliente solo está interesado en trabajar con

la abstracción. No obstante, el cliente tiene que vincular el
objeto de la abstracción con uno de los objetos de la
implementación. (Refactoring.Guru, s. f.,
https://refactoring.guru/es/design-patterns/bridge)

Figura 5: Pseudocódigo
Fuente: Refactoring.Guru. (s. f.). Pseudocódigo. Recuperado de
https://refactoring.guru/es/design-patterns/bridge.

[El diagrama anterior ilustra cómo] el patrón bridge  puede

aplicarse para dividir el código de una aplicación que gestiona
dispositivos y sus controles remotos. Las clases
dispositivo  actúan como Implementación, mientras que las
clases remoto actúan como abstracción.
 La clase base de control remoto declara un campo de referencia
que la vincula con un objeto de dispositivo. Todos los controles
remotos funcionan con los dispositivos a través de la interfaz
general de dispositivos, que permite al mismo remoto soportar
varios tipos de dispositivos.

Podemos desarrollar las clases de control remoto

independientemente de las clases de dispositivo. Lo único
necesario es crear una nueva subclase de control remoto. Por
ejemplo, puede ser que un control remoto básico cuente tan solo
con dos botones, pero podemos extenderlo añadiéndole
funciones, como una batería adicional o pantalla táctil.

El código cliente vincula el tipo deseado de control remoto con

un objeto específico de dispositivo a través del constructor del
control remoto. (Refactoring.Guru, s. f.,
https://refactoring.guru/es/design-patterns/bridge)

Veamos cómo sería el código en Java para este diagrama:

// La "abstracción" define la interfaz para la parte de

// "control" de las dos jerarquías de clase. Mantiene una

// referencia a un objeto de la jerarquía de "implementación" y

// delega todo el trabajo real a este objeto.

class RemoteControl is

  protected field device: Device

  constructor RemoteControl (device: Device) is

     this.device = device

  method togglePower () is

     if (device.isEnabled () ) then

       device.disable ()

     else

       device.enable ()

  method volumeDown() is

     device.setVolume (device.getVolume () - 10)

  method volumeUp () is

     device.setVolume (device.getVolume () + 10)

  method channelDown () is

     device.setChannel (device.getChannel () - 1)

  method channelUp () is

     device.setChannel (device.getChannel () + 1)

// Puedes extender clases de la jerarquía de abstracción

// independientemente de las clases de dispositivo.

class AdvancedRemoteControl extends RemoteControl is

  method mute () is

     device.setVolume (0)

 
// La interfaz de "implementación" declara métodos comunes a

// todas las clases concretas de implementación. No tiene por

// qué coincidir con la interfaz de la abstracción. De hecho,

// las dos interfaces pueden ser completamente diferentes.

// Normalmente, la interfaz de implementación únicamente

// proporciona operaciones primitivas, mientras que la

// abstracción define operaciones de más alto nivel con base en

// las primitivas.

interface Device is

  method isEnabled ()

  method enable ()

  method disable ()

  method getVolume ()
  method setVolume (percent)

  method getChannel ()

  method setChannel (channel)

// Todos los dispositivos siguen la misma interfaz.

class Tv implements Device is

  // ...

class Radio implements Device is

  // ...

// En algún lugar del código cliente.

tv = new Tv ()

remote = new RemoteControl (tv)

remote.togglePower ()

radio = new Radio()

remote = new AdvancedRemoteControl (radio)

(Refactoring.Guru, s. f., https://refactoring.guru/es/design-
patterns/bridge).

C O NT I NU A R
Lección 3 de 4

Referencias

Jesús Ramírez Guerrero (2014). Patrones de diseño en Java. Recuperado de

https://jesusramirezguerrero.com/2014/08/26/patrones-de-diseno-en-java/.

Junta de Andalucía (s.f.). Patrones de diseño. Recuperado de

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/13.

Refactoring.Guru (s. f.). Bridge. Recuperado de

https://refactoring.guru/es/design-patterns/bridge.

Refactoring.Guru (s. f.). Clasificación de los patrones. Recuperado de

https://refactoring.guru/es/design-patterns/classification.

C O NT I NU A R
Lección 4 de 4

Revisión del módulo

Hasta acá aprendimos

Introducción a los paradigmas de programación

–
Los paradigmas de programación son diferentes modelos que se adaptan a la
solución de diferentes situaciones problemáticas. Pueden clasificarse en
imperativo, orientado a objetos y declarativo. El paradigma de programación
orientado a objetos plantea un modelo de la situación a resolver, teniendo en
cuenta solo las características involucradas en la solución.

Preparar el camino hacia la utilización de patrones de diseño

–
Un patrón es un esqueleto de solución a un problema con determinadas
características de base. Para comprender y ejercitar el uso de patrones nos
apoyaremos en el uso de diagramas UML y la plataforma de programación Java.

Patrones, tipos e importancia

–
Utilizamos patrones porque son soluciones testeadas y predeterminadas a
problemas con ciertas características. Permiten que un equipo de programadores
trabaje sobre un problema con un lenguaje común. Los patrones pueden
clasificarse, según la etapa de aplicación, en: arquitectónicos, de análisis, de
diseño o idiomas.

Clasificación de patrones de diseño

–
“Los patrones de diseño pueden clasificarse en creacionales, estructurales o de
comportamiento” (Profile Software Services, S.L, 2020,
https://profile.es/blog/patrones-de-diseno-de-software/).
“Los patrones de diseño creacionales se centran en la creación de objetos”
(Kotlin, Desarrollador Android, s.f., https://kotlin.desarrollador-
android.com/category/patrones-de-diseno/patrones-creacionales/) de forma
adecuada según la situación problemática. Los patrones de diseño estructurales
identifican las relaciones entre las entidades. Los patrones de diseño de tipo
comportamiento identifican los patrones comunes de comunicación entre
objetos.