Algunos pensamientos sobre el libro "Design Patterns"

Recientemente volví a leer el libro de Design Patterns: Elements of Reusable Object-Oriented Software de Gamma et al. (mejor conocidos como Gang of Four), y es agradable darme cuenta de lo actual que aún resulta, incluso siendo un libro escrito en 1994. Aunque muchos libros sobre tecnología específica tienen una caducidad implícita (y usualmente corta) por la naturaleza del tema que tratan, hay otros libros sobre tecnología, que tienden más hacia la ciencia, que lograr trascender su expectativa de vida útil.

Yo estudié mi ingeniería en el área de la electrónica pero mis estudios posteriores fueron en el área de las ciencias computacionales, y en dicha área desarrollé la mayoría de mi experiencia profesional. Una de las cosas que descubrí en ese periodo es que me hubiera sido útil conocer de antemano los patrones. A través de la práctica de programación ya tenía la noción de lo que eran, aunque no supiera su nombre, incluso ya había "descubierto" ciertos patrones por mi cuenta. Pero al leer sobre patrones por primera vez, hace ya varios años, al ver algunos de los patrones, su utilidad, sus posibles implementaciones, fue uno de esos momentos eureka, y que me permitieron asignar un nombre a ese concepto que mental que estaba flotando en mis pensamientos.

Pero, ¿qué es un patrón, un patrón de diseño? Según el libro, es un mecanismo que permite nombrar y explicar diseños genéricos que atacan problemas recurrentes en los sistemas orientados a objetos; estos describen el problema, la solución, cuándo aplicar la solución, y sus consecuencias. Tienen un símil con el uso de patrones en otras áreas, como la arquitectura, y obviamente le hacen honor a una de las acepciones de la palabra patrón: modelo que sirve de muestra para sacar otra cosa igual.

Sin embargo, es importante resaltar que un patrón de diseño (en el software) no incluye una implementación en algún lenguaje de programación en particular, si no una forma de generar una solución a un problema, pero es un tipo de solución que ya había sido hecha (potencialmente) bajo otro contexto. Y esta re-utilización del conocimiento de la solución es lo que se describe en un patrón.

Regresando al libro, su re-lectura me permitió darme cuenta que algunas cosas pudieran tener mejor ejemplos hoy día porque el lenguaje que utilizaron para ello (C++ y Smalltalk) ha evolucionado y ahora tiene características que permiten una mejor implementación. Por ejemplo, la idea de las “interfaces” ya está ampliamente extendida en nuevos lenguajes de programación y ya se podría dejar de hablar de clases abstractas para representar interfaces. Otro ejemplo son las funciones lambda que ya existen en C++. De hecho, esta situación es una de las críticas principales a este libro, ya que algunos se han encargado de marcar como inútiles algunos de los patrones ya que algunos lenguajes de programación ya tienen soporte nativo para proporcionar las funcionalidades deseadas. Empero, en mi opinión, la teoría detrás de los patrones de diseño sigue siendo muy útil.

Como referencia, los patrones que vienen en el libro son los siguientes. Patrones creacionales: Abstract Factory, Builder, Factory Method, Prototype, Singleton. Patrones estructurales: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy. Patrones comportamentales: Chain of Responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

A manera de conclusión, creo que este es uno de esos libros que todo ingeniero relacionado al software debería tener en la biblioteca personal para mantenerlo como referencia. El mismo espíritu que refleja, si lo logramos interiorizar, nos permitirá pasar de programador a arquitecto de software (si eso es lo que deseamos). Sería interesante que hicieran una nueva edición y ver como actualizarían el contenido.