La programación orientada a objetos (POO) tiene ya más de 40 (¿50?) años y sin embargo….

Para empezar me parece importante destacar el hecho que la POO no solo es una «tecnología de programación» sino algo mucho más amplio: es un paradigma. Esto implica que además de programar utilizando ciertas herramientas (encapsulamiento, polimorfismo, etc, etc), también tiene impacto en la forma en que planteamos los problemas y diseñamos nuestras soluciones.

Hoy en día creo que todos los lenguajes de programación de uso masivo tienen soporte para POO. Al mismo, en las carreras universitarias de sistemas se enseña POO.

Sin embargo, una y otra vez vemos (en la industria y en la academia) soluciones que utilizan objetos pero que no son orientadas a objetos. Abundan las soluciones con objetos contenedores de datos por un lado y objetos con lógica/algoritmos (pero sin datos) por otro. Para el resto del artículo me voy a referir a estas soluciones como «soluciones procedurales (SP)». Este fenómeno de «datos por un lado» y «comportamiento por otro», no es nuevo. De hecho hay varios frameworks que proponen este enfoque. Ya desde los años 2000 J2EE proponía nombre a estos objetos: «session beans» y «entity beans». Esta estrategia puede resultar práctica e incluso conveniente pero es contraria a la propuesta de la orientación objetos donde se supone que cada objeto encapsula dentro de sí, datos y los algoritmos que operan sobre esos datos.

A esto se suma al hecho de que hay gente que cree que construye soluciones orientadas a objetos porque usan clases, herencia, y demás herramientas de la OO pero que en realidad son soluciones procedurales porque siguen separando datos y comportamiento.

No digo que esté mal hacer soluciones procedurales, de hecho creo que hay situaciones donde este enfoque puede ser el más conveniente. Pero esta confusión entre soluciones procedurales y soluciones orientadas a objetos traen dos situaciones potencialmente problemáticas.

Un problema es cuando decimos (o creemos) estar haciendo algo (una solución OO) pero en realidad estamos haciendo algo distinto (una solución procedural).

El otro problema es usar un enfoque cuando en realidad sería mejor utilizar el otro.

Los primeros 15 años de mi trabajo docente fue intentando enseñar POO y por ello soy consciente de la dificultad de enseñar/aprender este tema. Hoy en día en los cursos que dicto en la universidad se supone que los alumnos ya llegan sabiendo OO aunque lamentablemente en la mayoría de los casos vemos importante falencias. Creo que en parte esto se debe a que muchas veces se enseña OO utilizando «problemas simplificados», o sea: los alumnos saben hacer modelos computables orientados a objetos de ciertos problemas, pero sin tener que lidiar con infraestructura (interfaces de usuario, persistencia, etc.).

Lo que veo en mis cursos es que cuando les planteamos problemas en los que tienen que lidiar interfaces de usuario, persistencia, etc, se «desvían» y terminan haciendo soluciones procedurales :-(.