Programación Orientada a Objetos con Lenguaje C

Hace un buen rato, en la época que el Lotus 123 dominaba en las hojas de cálculo, que leí un excelente artículo que se denominaba: Programación Orientada a Objetos con Lenguaje C.

Si, no hay error. No falta un ++ allí. Es POO con el maravilloso lenguaje C.

El artículo en cuestión, proponía como utilizar las estructuras de datos y punteros de C para emular el comportamiento de Clases y Objetos. Hacía énfasis en diversas técnicas para aprovechar el encapsulamiento, la herencia y otros principios y conceptos de la POO con el C. Acá un enlace a una publicación que menciona algunas de estas técnicas.

Esencialmente se fundamentaba en el tipo de dato “Struct” de C con punteros como referencias a los métodos y funciones que manipulaban estas estructuras de datos. Esto es válido en el contexto en el que sostienen que una Clase es un tipo de datos definido por el usuario y que encapsula a los Datos y los Métodos relacionados.

Como dije, eso está muy bien en ese contexto. Y funciona como maniobra de desarrollo interesante dentro del ámbito del lenguaje C.

No obstante, hay algo intrínsecamente  erróneo con este concepto a nivel de la POO. Es más, hay algo que huele mal con la POO por sí misma.

Según esta forma de enfocar las cosas, Un Objeto y su definición, la Clase, no son más que estructuras de datos con funciones que los manejan. Eso es esencialmente programación estructurada con Clases!!!! NO PROGRAMACIÓN ORIENTRADA A OBJETOS.

Este enfoque pernicioso se ha mantenido por décadas en centros académicos y de desarrollo. Afirmo categóricamente que una gran mayoría de los muchos programadores que usan lenguajes orientados a objeto, programan en forma estructurada, pero usando clases y los supuestos recursos y conceptos de la POO.

Concebir las clases como simples repositorios de datos. Hacer énfasis en los métodos o funciones que manipulan esos datos o atributos, es básicamente lo que se venía haciendo con los lenguajes procedimentales desde hace mucho tiempo. De hecho, con esta forma de ver la POO, sólo se ha conseguido agregar una artificiosa complejidad a los sistemas y programas, sin ganar mucho, o más bien nada, en el manejo adecuado de esa complejidad.

Hoy, y como herencia prolongada, abundan los POJOS, BEANS y demás clases Contenedoras, simples estructuras de datos con métodos asociados, en un sin número de sistemas desarrollados. Peor aún, casi todas esos objetos o instancias son Mutables!!! Lo que acarrea problemas de gestión en multitarea o programas ThreadSafe.

Pululan las librerías llenas de antipatrones, malas prácticas y mecanismos heredados que simplemente replican un modelo que bien podría ser mantenido con otros lenguajes. Donde el uso de la POO es más una cuestión de sintaxis y gramática que de fondo, funcionalidad y contenido en los sistemas y sus clases componentes.

En otras palabras, seguimos programando en forma estructurada. Así de simple. Que ahora lo hacemos con Java, C++ y demás lenguajes por el estilo, es incidental. No hay aportes sustanciales en la forma de programación. En las clases, en sus objetos instanciados, en los mecanismos de comunicación, en la organización de los sistemas y los medios de persistencia. TODOS ellos son sólo variaciones de formas procedimentales y estructuradas de desarrollo de software. Poco que ver con lo que denomino POO real. Tenemos programadores que creen que “encapsular” es meter los datos y sus manipuladores bajo un denominador común, sin entender que el encapsulamiento se refiere más al comportamiento y algoritmos que a las estructuras de datos. Contamos con programadores que son incapaces de concebir soluciones con Clases Inmutables. Es más, ni siquiera saben cómo diseñarlas y usarlas. Programadores que aún abusan de la herencia como forma de implementación del polimorfismo y reutilización de componentes, y así una larga lista de etcéteras y etcéteras.

Para leer un poco más del tema, recomiendo este artículo de Yegor Bugayenko que versa un poco sobre este tema.

Corrijo entonces mi planteamiento.

No hay algo intrínsecamente erróneo con la POO. Hay algo sustancialmente malo con  LOS PROGRAMADORES que usan lenguajes Orientados a Objetos.

Como siempre, la diferencia está en la gente.