Ventaja oculta de no usar c++ clases: cuando agregas una nueva función no tienes que registrarla en la clase, la escribes, la usas y ya.

Prometo que este va a ser mi último post “yo uso C++ pero no uso clases“. Quiero concentrarme en el tema de la complejidad en si misma y olvidar otros temas. No he querido buscar en wikipedia como se llama el síndrome de los que piensan “por qué hacerlo sencillo si lo podemos hacer complicado“, estoy seguro que este síndrome tiene un nombre. Bueno, yo sufro de ese síndrome. Por ejemplo, cuando abandoné mi juego psyblast (para los que nos visitan por primera vez yo tengo una enorme colección de juegos inconclusos, es parte de mi hobbie, comenzar juegos y no terminarlos, es divertido sugiero intentarlo) decidí que mi próximo juego sería algo simple, muy simple, un juego en el espacio, donde el jugador tiene una consola donde pueda ver diversos medidores, y el juego sea simplemente tratar de viajar lo más lejos optimizando el uso de combustible, oxigeno, hidrógeno, etc.

5 años después esto se convirtió en khpx, un juego de estrategia con elementos del género 4x (eXploración, eXpansión, eXplotación, eXterminio) (pero no es un juego 4x) donde el jugador puede practicar la minería, la cosecha, desarrollo de tecnología, y en general desarrollo y dominio de recursos. Y sigue y sigue complicándose hasta el infinito. Así que todos los días mi motto es “cómo hago para simplificar las cosas” o “qué puedo simplificar hoy”.

Como mi compulsión me impide simplificar más allá de cierto nivel el juego, apunto mis baterías a C++. ¿Qué más puedo simplificar? No mucho pero contener mi impulso natural a usar clases ya es un comienzo.

Entonces cayó en mis manos este software, recientemente liberado por EA, el código fuente de CnC(Command & Conquest). C++. Clases. Muchas. Ví archivos muy grandes, vi un caos en la nomenclatura de los archivos, los nombres de clases, variables, métodos, todo. Y sentí un alivio porque así es khpx: un caos de nomenclatura donde hay funciones_con_barra_de_abajo, funcionesConNotacionCamel, variables_con_la_funcionalidad_al_comienzo y demás cosas similares.

CnC tiene un DISPLAY.CPP (de 190k) y un DISPLAY.H de 13k (en khpx el archivo más grande tiene 40k y es mucho) Ví cosas como DisplayClass::TacticalClass::Command_Object (..), y mezclado con esto, muchas funciones static funcion_no_en_una_clase_y_es_libre (…). Lo cual me lleva a pensar cuál es el punto. Sin embargo, el código se deja leer, el nivel de espaguetismo es minimo (khpx es un espagueti de pasticho hecho con pasta corta). Ahora, en el código de CnC seguir el camino de las clases esa es otra historia: entre algo->subalgo (..) mezclado con OtroAlgoSolo(…) entender quién llama a quién desciende a un nivel de complejidad natural, porque está implementando un juego naturalmente complejo, complicado por la complejidad de la capa de clases mezclada con funciones estáticas imposibles de meter en clases porque son libres como el viento. La idea de las clases es organizar la complejidad, a veces con éxito, a veces agregando una nueva capa de complejidad a la complejidad para que la complejidad subyacente sea invisible, aunque nosotros sabemos que está ahí, e inevitablemente nos devora como arenas movedizas.

Es decir, buen intento, pero las clases en sistemas complejos fracasan en hacer amigable la complejidad, simplemente la ocultan y la hacen más compleja a niveles inmanejables.

Este nivel de complejidad innecesario y a veces inútil (estas palabras no son sinónimos), es como el síndrome de willicoyotismo (algo que acabo de inventar) Willie el Coyote quiere atrapar al correcaminos (en la vida real un coyote alcanza en una carrera a un correcaminos en cuestión de 30 segundos) pero utiliza catapultas, cuerdas atadas a un risco, y se coloca un casco con una rueda arriba, y patas para arriba se lanza sobre la cuerda corriendo con la rueda que tiene en el casco como un funicular invertido. También arroja misiles, bombas, tumba puentes etc. Es lo mismo que utilizar los artefactos alrededor de las classes de OOP. ¿Ejemplos? Bueno este señor quería calcular la desviación estándar para las mediciones de un sensor. Lo que hizo fue tener una clase Sensor y una clase Medida, y cada vez que quería calcular la desviación estándar, convertía los valores tipo double a Medidas, los cargaba en un Sensor, llamado “CalculateStDev”, y tomaba la propiedad “CurrentStdDev” del Sensor. ¿Ok? ¿Cuál es la diferencia entre eso y meterse en un cañon como el hombre bala, activar el disparador calculando que la trayectoria dé exactamente en el sitio donde el correcaminos va corriendo por una carretera cualquiera a una velocidad de 24 km por hora ? Yo no veo la diferencia honestamente.

Como un ejemplo adicional, este señor muestra como OOP es inconveniente en algunos casos (realmente todos) y cómo una solución escrita con clases puede ser escrita fácilmente con una simple función. En realidad, cuando resolvemos un problema, es en el problema en que debemos estar pensando, no en cómo usamos nuestro lanzamisiles de última generación para resolver el problema. Lo cual es la principal razón por la que dejé de usar clases. Pierdo mucho tiempo pensando en cómo emplear sus patterns para resolver problemas, en vez de simplemente resolver el problema.

Esta pérdida de perspectiva termina desvirtuando “lo que tienes que hacer” de maneras incomprensibles. Es como ciertos gerentes de proyecto que manejan los proyectos usando el software, viendo las actividades en gráficos y los tickets cambiando de estatus. Quizás ves algunas cosas pero no el conjunto y sus interacciones, y tus acciones y rabietas terminan siendo absurdas. Los demás te miran desde el otro lado de la mesa con perplejidad: ¿qué le pasa?.