Ir al contenido principal

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.

Comentarios

Publicar un comentario

Entradas populares de este blog

El Melange todavía corre

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

Primeros pasos con Camunda BPM – Modelando un Proceso BPMN 2.0

Tenemos entre manos la tercera publicación de nuestra serie sobre la Plataforma de BPM de Camunda .  El día de hoy vamos, por fin, a empezar a modelar o construir nuestro primer proceso sencillo en notación BPMN 2.0. Para ello vamos a usar el modelador o editor que ya hemos instalado en nuestra primera publicación , y vamos a guardarlo en la sección de recursos del proyecto Maven Java que configuramos en la segunda publicación . Así que, como ya es costumbre, manos a las sobras…

Como configurar jBPM para usar nuestra propia Base de Datos en un sólo paso

Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada. Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento.  Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida. En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM. Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita. Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera. Así que manos a l