Si quieres ampliar las funcionalidades de una clase en un software orientado a objetos, tienes dos opciones. La opción más fácil es implementar subclases que complementen a la clase base. Sin embargo, esta opción puede volverse confusa. Como alternativa, puedes usar una entidad decoradora según el llamado patrón de diseño Decorador (Decorator Design Pattern). El patrón, que es uno de los 23 Gang of Four (GoF) Design Patterns, permite una expansión dinámica de las clases mientras el software está en funcionamiento. Es más, el patrón Decorador funciona sin recurrir a jerarquías de herencia largas y de difícil comprensión.
A continuación, te explicaremos qué es exactamente un patrón de diseño Decorador y cuáles son sus ventajas y desventajas y mostraremos su mecánica mediante un gráfico y un ejemplo práctico.
El patrón de diseño Decorador es una estrategia de diseño revelada en 1994 para expandir la funcionalidad de las clases dinámicamente en el software de computación orientado a objetos. Según este patrón, cualquier objeto puede complementarse con un comportamiento deseado sin influir en las funcionalidades de otros objetos de la misma clase. Desde el punto de vista estructural, el patrón Decorador tiene mucho en común con el patrón Cadena de Responsabilidad (Chain of Responsibility), aunque, en contraste con este, con un procesador central, todas las clases reciben las peticiones.
El componente de software que hay que ampliar se “decora” con una o más clases decoradoras, que lo envuelven completamente, siguiendo el patrón de diseño Decorador. Cada decorador es del mismo tipo que el componente al que envuelve y, por lo tanto, tiene la misma interfaz. De esta manera, las llamadas de método entrantes pueden delegarse fácilmente al componente adjunto mientras lleva a cabo una funcionalidad. Las llamadas también pueden procesarse dentro del decorador.
Al igual que otros patrones GoF, como, por ejemplo, el patrón Strategy o el Builder, el patrón Decorator tiene como objetivo hacer que los componentes del software orientado a objetos sean más flexibles y fáciles de reutilizar. Con este fin, el enfoque permite a los desarrolladores añadir y eliminar las dependencias de un objeto de manera dinámica y, cuando sea necesario, durante el tiempo de ejecución. Esto convierte al nombrado patrón en una buena alternativa al uso de subclases, las cuales pueden complementar a una clase, pero no permiten hacer ajustes durante el tiempo de ejecución.
Un componente de software puede ampliarse con un número cualquiera de clases decoradoras. Estas extensiones son invisibles, lo que significa que normalmente es difícil percibir si una clase real está precedida por clases adicionales.
El decorador, o las clases decorador (ConcreteDecorator), tiene la misma interfaz que el componente de software a decorar (ConcreteComponent) y es del mismo tipo. Estos son requisitos importantes a la hora de manejar las llamadas, que pueden remitirse con o sin cambios en función de si el decorador no se encarga de procesarlas. En este concepto, esta interfaz elemental, que es esencialmente una superclase abstracta, recibe el nombre de “componente”.
La interacción entre el componente básico y el decorador es fácilmente visible si se ilustra con un diagrama de clases UML. Hemos utilizado este lenguaje de modelado para la programación orientada a objetos en el diagrama UML a continuación para entender el patrón Decorator:
Considerar el patrón de diseño Decorator al diseñar un programa es útil por varias razones. En primer lugar, utilizar la estructura Decorador conlleva un alto grado de flexibilidad: las funcionalidades de las clases pueden ampliarse durante la compilación y durante el tiempo de ejecución sin necesidad de recurrir a una jerarquía de clases basadas en la herencia. Esto mejora significativamente la legibilidad del código del programa.
Debido a que la funcionalidad se divide en varias clases decoradoras, el rendimiento del software puede incrementarse. Esto facilita la recuperación e iniciación de funciones específicas. Con una clase base compleja que proporciona permanentemente todas las funciones, esta opción de recursosoptimizados no está disponible.
Sin embargo, desarrollar usando el patrón Decorador tiene también algunas desventajas. Con la introducción del patrón aumenta la complejidad del software de forma automática. La interfaz Decorador, en particular, suele contener mucho texto y términos nuevos, lo que aumenta su complejidad. Otra desventaja es el gran número de objetos Decorador, razón por la cual se recomienda una sistematización separada para evitar problemas de visualización al trabajar con subclases. Por último, las largas cadenas de llamadas de los objetos decorados (es decir, los componentes ampliados) suelen dificultar la detección de errores y por ende también el proceso de depuración.
| Ventajas | Desventajas |
|---|---|
| Alto grado de flexibilidad | Alta complejidad del software (especialmente la interfaz Decorador) |
| Ampliación de las funciones de las clases sin herencia | De difícil comprensión al principio |
| Código de programa legible | Alto número de objetos |
| Funcionalidades optimizadas para los recursos | Proceso de depuración difícil |
El patrón Decorador proporciona la base para implementar objetosdinámicos, transparentes y expandibles en un programa. En particular, los componentes de las interfaces gráficas de usuario (GUI) figuran como áreas de aplicación típicas del patrón. Si, por ejemplo, se debe enmarcar un campo de texto, basta con emplazar un decorador “invisible” entre el objeto campo de texto y la llamada para insertar el nuevo elemento de la interfaz.
Un ejemplo muy conocido de la implementación del patrón Decorador lo constituyen las llamadas clases stream de la biblioteca de Java, respondables de gestionar la entrada y salida de datos. Aquí, las clases Decorador se utilizan para añadir nuevas propiedades e información de estado al flujo de datos o para proporcionar nuevas interfaces.
Java no es el único lenguaje de programación que hace un uso generalizado del patrón Decorador. Los siguientes lenguajes de programación también lo utilizan:
Como acabamos de ver, el patrón Decorador no es adecuado para todos los tipos de software. Sin embargo, cuando una clase tiene que modificarse a posteriori, y especialmente en proyectos en los que esto no se puede conseguir mediante el uso de subclases, el patrón Decorador es una gran solución.
En el ejemplo que presentamos a continuación, el punto de partida es un programa que permite consultar nombres de personas a través de la clase abstracta “Empleado”. Sin embargo, la primera letra de los nombres recuperados siempre está en minúsculas. Al ser imposible un ajuste en retrospectiva, se implementa la clase Decorador EmpleadoDecorator, que opera en la misma interfaz y también permite llamar al método getName(). El decorador recibe una lógica que garantiza que la primera letra se escribe correctamente en mayúsculas. En código, esto se escribe así:
public class EmpleadoDecorator implements Person {
private Empleado empleado;
public EmpleadoDecorator(Empleado empleado){
this.empleado = empleado;
}
public String getName(){
// llama al método de la clase empleado
String name = empleado.getName();
// Asegúrate de que la primera letra está en mayúsculas
name = Character.toUpperCase(name.charAt(0))
+ name.substring(1, name.length());
return name;
}
}
Los dark patterns están en todas partes en la red. Los encontrarás en tiendas en línea, servicios de correo electrónico, portales de descarga, motores de búsqueda y redes sociales. El objetivo es siempre el mismo: manipular al usuario para que ejecute alguna acción contra de su voluntad, como comprar productos o hacer clic en enlaces, por ejemplo. Te mostramos qué son los dark patterns, cómo...
Con el fin de unificar los métodos de programación más importantes y hacerlos más sencillos de comprender, en 1994 cuatro informáticos publicaron un libro con más de 20 patrones de programación específicos y sus explicaciones. Uno de estos patrones es el llamado visitor pattern que separa los algoritmos de un módulo de software y sus funciones de la estructura del objeto subyacente. ¿Cómo funciona...
El patrón de diseño Observer o, simplemente, patrón Observer, es el enfoque de desarrollo ideal cuando se dispone de muchos objetos que requieren información sobre el estado actual de otro objeto concreto. Con este concepto, todos los cambios son transferidos, de forma automática, por el objeto observado. ¿Cómo funciona exactamente este proceso y para qué tipos de software es apropiado el patrón...
Si quieres separar la creación de clases u objetos de la clase principal, lo que necesitas es un Factory Pattern o patrón Factory. Este patrón de diseño consigue delegar en las subclases el proceso de creación para que la clase padre sea tan flexible como sea posible para las extensiones. Pero ¿cómo funciona el patrón de diseño Factory y qué ventajas tiene?
Ofrece un servicio fiable y de alto rendimiento a tus clientes con un pack hosting de IONOS.
