Design patterns: programar de manera más rápida y segura
Equipo editorial de IONOS7 mins
Cada diseño tiene su patrón y todo tiene su propio modelo, sea una taza, una casa o un vestido. A nadie se le ocurriría la idea de poner el asa de una taza al interior de la misma, ya que para la utilización práctica está demostrado que es mejor colocar este elemento en el exterior. Por esto, si vas a un curso de alfarería y quieres hacer una vasija con asas, ya conoces la forma básica; en tu cabeza ya está guardada como patrón de diseño.
El mecanismo es similar con los programas informáticos. Hay determinados procesos que siempre se repiten, de tal forma que solo hay que dar un pequeño paso para crear un patrón. A continuación explicamos cómo estos design patterns (patrones de diseño) te pueden facilitar las tareas de programación.
¿Qué son los design patterns?
El concepto design pattern se remonta al arquitecto norteamericano Christopher Alexander, que reunió patrones reutilizables formando una colección. Su intención era involucrar a los futuros usuarios de las construcciones en el proceso de diseño. Esta idea fue entonces adoptada por un número de científicos informáticos. El denominado Gang of Four (GoF) —Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides— contribuyó en el año 1994 al éxito de los software patterns con su libro Design Patterns – Elements of Reusable Object-Oriented Software.
Entonces, ¿Qué son los design patterns? Vamos a continuar utilizando nuestro ejemplo anterior: para cada taza —ya sea de café o de té— siempre se necesitan los mismos elementos básicos: base, paredes y asa. Esto sucede de manera similar en la programación: los bucles que se deben recorrer siempre están vinculados a los requisitos iniciales y finales; una condición siempre requiere una decisión sobre lo que ocurre si se cumplen estos requisitos y lo que ocurre si no se cumplen; un cálculo siempre da como resultado la combinación de variables, etc. A partir de muchos de estos pasos de programación individuales se crea una secuencia de programa que siempre se desarrolla de la misma manera para determinadas tareas. Los patrones de diseño de software son una descripción de cómo resolver un problema.
A continuación presentamos un ejemplo muy sencillo de un software pattern, en este caso, un factory pattern:
class Tazas
{
private $tazaMake;
private $tazaModel;
public function __construct($make, $model)
{
$this->tazaMake = $make;
$this->tazaModel = $model;
}
public function getMakeAndModel()
{
return $this->tazaMake . ' ' . $this->tazaModel;
}
}
class TazasFabric
{
public static function create($make, $model)
{
return new Taza($make, $model);
}
}
$expreso = TazasFabric::create('Taza', 'Expreso'); // El objeto se ha creado
print_r($expreso->getMakeAndModel()); // Salida "Taza Expreso"Lo mismo es aplicable a contextos y procesos más amplios que se utilizan de manera recurrente para resolver ciertas tareas en las secuencias de programas. El ejemplo de código se puede ampliar a voluntad y también aplicar a otros sectores, productos y procesos diferentes. Además, por supuesto, solo se trata de un componente dentro un software más completo. De esta forma, los patrones de diseño se entienden como esquemas que ya se han probado en la práctica.
¿Qué tipo de design patterns hay?
Los tipos de patrones de diseño representan las áreas de aplicación básicas de los patrones de software que reúnen.
Patrón de estructura
Los structural patterns son plantillas ya listas para relaciones entre clases. El objetivo es lograr una abstracción que también se pueda comunicar con otros enfoques de solución. El concepto clave es la programación de interfaces.
Patrón de comportamiento
Con los behavioral patterns se modela el comportamiento del software. Estos patrones simplifican los complejos procesos de control. Para ello, se puede elegir entre algoritmos y las responsabilidades de los objetos.
Patrón de creación
Con los creational patterns se crean objetos que permiten una representación simplificada de los procesos para determinadas instancias. Este proceso funciona independientemente de la manera en la que cada uno de los objetos se cree y se represente en un software.
Con el paso del tiempo, han surgido más tipos de patrones de diseño que no encajan en ninguna de las categorías mencionadas. Entre ellos se encuentran los patrones para el mapeo objeto-relacional, con los que se almacenan los objetos y sus relaciones en una base de datos relacional.
Luces y sombras de la utilización de los design patterns
Ventajas
La posibilidad de recurrir a planteamientos de solución probados va acompañada de un ahorro de tiempo y costes. Los equipos de desarrolladores no necesitan inventar una y otra vez la máquina para resolver, en cada nuevo flujo de programa, subtareas que ya se han resuelto en multitud de ocasiones. Las denominaciones de los patrones suelen provenir de un vocabulario de diseño común que simplifica tanto la comunicación entre desarrolladores como con el usuario de la futura solución. También la documentación de un software se simplifica cuando se utilizan componentes ya documentados. Estas ventajas también se aprovechan durante el mantenimiento y posterior desarrollo de un programa.
Inconvenientes
El tratamiento de los patrones de diseño requiere amplios conocimientos previos. La disponibilidad de los design patterns también puede inducir a creer que, si se cuenta con patrones de diseño, aparentemente todos los problemas quedan resueltos. En resumen: la creatividad puede quedar limitada, al igual que la curiosidad para encontrar nuevas (y mejores) soluciones.
¿Qué design patterns conocidos hay?
Existen más de setenta patrones de diseño que pertenecen a diferentes categorías. Algunos software patterns importantes son, por ejemplo, los siguientes:
Patrón de creación
- Builder pattern: el constructor de la categoría del patrón de creación separa el desarrollo de objetos (complejos) de sus representaciones.
- Factory pattern: este patrón de diseño genera un objeto a modo de patrón de creación recurriendo a un método en lugar de un constructor.
- Singleton pattern: la instancia única garantiza, como patrón de creación, que únicamente exista solo un objeto en cada clase. Además, el singleton está disponible a nivel global.
Patrón de estructura
- Composite pattern: un patrón de estructura compuesto que está especialmente orientado al tratamiento de estructuras dinámicas, por ejemplo para la organización de archivos o la compresión de datos.
- Decorator pattern: el llamado decorador integra más funciones o competencias en clases existentes.
- Facade pattern: la fachada representa la interfaz para los demás sistemas y sub-sistemas.
Patrón de comportamiento
- Observer pattern: el observador transmite las modificaciones de un objeto a estructuras que dependen del objeto inicial.
- Strategy pattern: la estrategia define una familia de algoritmos intercambiables.
- Visitor pattern: el visitante aísla operaciones ejecutables, de tal forma que se puedan llevar a cabo nuevas operaciones sin modificar las clases afectadas.
Los design patterns presentan patrones listos para utilizar con los que, para solucionar un problema explícito, se recurre a un concepto probado. El patrón se basa en software designs existentes e involucra al usuario de la futura solución en el proceso de diseño. Los patrones de diseño no están ligados a ningún lenguaje de programación, lo que hace que su utilización sea universal.
