Los patrones de diseño nacieron bajo el paraguas de la programación orientada a objetos, pero eso no significa que dependan exclusivamente de ella. Comprender esta relación —y repasar los fundamentos del paradigma— es clave para aplicar patrones con soltura en cualquier proyecto de software.
¿Existe una dependencia entre la programación orientada a objetos y los patrones de diseño?
El libro clásico de patrones de diseño, escrito por los cuatro autores conocidos como Gang of Four, fundamentó todas sus ideas en el paradigma orientado a objetos [0:20]. Si revisas la bibliografía disponible, la mayoría de los ejemplos y diagramas muestran clases, relaciones entre clases y líneas que representan asociaciones. Eso puede dar la impresión de que ambos conceptos son inseparables.
Sin embargo, no existe una relación de dependencia [1:07]. Los patrones de diseño pueden aplicarse a diversos paradigmas, incluida la programación funcional. Que los diagramas más populares utilicen clases no implica que el patrón solo funcione dentro de ese modelo. Es simplemente el contexto histórico en el que se formularon.
¿Qué son los objetos y las clases en este paradigma?
La programación orientada a objetos (POO) basa el diseño de software alrededor de la figura de los objetos: elementos que contienen propiedades y comportamiento [1:48]. Este enfoque recoge un proceso llamado abstracción, que consiste en tomar una idea del mundo real y trasladarla al código.
- Los objetos pueden representar entidades tangibles como una persona.
- También modelan elementos intangibles, como una conexión a base de datos [2:24].
- Aunque no puedas "tocar" una conexión, sabes que tiene propiedades y comportamientos necesarios para funcionar.
Un ejemplo sencillo es la clase Persona, con atributos como first name y last name, y métodos como correr y caminar [2:46].
¿Cuáles son los cuatro pilares de la programación orientada a objetos?
La POO se sostiene sobre cuatro pilares que conviene tener frescos, porque acompañan todo el estudio de patrones de diseño [3:00]:
- Abstracción: capacidad de representar elementos de la vida real en código, capturando su comportamiento y características esenciales.
- Encapsulación: cada clase realiza tareas y posee propiedades completamente únicas, manteniendo sus detalles internos protegidos del exterior [3:22].
- Herencia: permite crear superclases (clases padre o ancestros) y clases que hereden sus atributos y comportamientos, de forma similar a cómo heredamos rasgos físicos de nuestros padres [3:40].
- Polimorfismo: es la capacidad que tienen los objetos de redefinir el comportamiento heredado [4:12]. Si tu clase padre corre de una forma, la clase hija puede correr de otra manera distinta o mantener el comportamiento original sin problema.
¿Por qué importan estos pilares al estudiar patrones de diseño?
Estos cuatro conceptos no son solo teoría académica. A lo largo de cualquier curso de diseño de software, las ideas de objetos, clases y sus relaciones van a estar presentes de forma constante [4:38]. Entender la abstracción te ayuda a modelar entidades; la encapsulación te permite delimitar responsabilidades; la herencia y el polimorfismo son la base de patrones como Strategy, Template Method o Factory.
Si alguna vez pensaste que la programación orientada a objetos y los patrones de diseño no podían vivir el uno sin el otro, ahora sabes que los patrones trascienden el paradigma, aunque la POO siga siendo el lenguaje más común para explicarlos. Comparte en los comentarios si ya conocías esta distinción o si cambia tu forma de ver los patrones.
