La verdad oculta tras los tipos de datos.

Es evidente que las metodologías nos alejan de la forma en la que trabaja el procesador. Pero lo hacen en favor nuestro. Siempre he pensado que las metodologías son como la “religión” en el software. Uno es libre de adoptar una o ninguna, e incluso de aunar varias para construir sus propias reglas.  Trabajar sin un conjunto de normas puede ser muy bueno o muy muy malo.

Ejemplo. Siempre recomiendan que las variables tengan un nombre “adecuado”. Desde el principio he pensado en qué querrá decir adecuado. Cada uno tenemos una forma de trabajar y lo que para uno es adecuado para otro no lo es. Pero si pensamos en que una variable ocupa “una dirección de memoria” y todos los bytes (sizeof(tipo_de_esa_variable)) que le acompañan, podemos pensar que definir variables alegremente es pernicioso. Si le damos un nombre adecuado, siempre podremos re-usar variables sin necesidad de tener que crear miles de ellas, cada una para un propósito diferente.

Luego, según en que casos, las metodologías también ayudan a alcanzar “rendimiento” en la computación. Como es el caso de la orientación a objetos. Claro, ayudan a alcanzar alto rendimiento, en lenguajes suficientemente alejados del procesador, como los que se diseñan para programar en ese paradigma. El ejemplo de la utilidad de las metodologías lo tenemos presente a la hora de crear las clases y la relación entre ellas para “modelar” un problema. Si seguimos las normas y realizamos un diseño limpio, nuestro programa puede llegar a ser óptimo. De no seguir la metodología, la semántica de la ejecución, incluso, puede verse afectada.

En otros casos como en los de los lenguajes de bajo nivel, la metodología no es de gran ayuda, aunque sirve para “organizar” y “compartir” el código. Como en el caso del lenguaje C, en el que siempre se recomienda crear funciones y llamar funciones en tiempo de ejecución. Cuando debido al modo de operación de los procesadores, este modo de trabajo es ineficiente (de ahí que surgieran en estos lenguajes palabras clave como “inline” para poder aliviar el impacto de la metodologia).

¿La orientacion a objetos solo puede entenderse desde la perspectiva de una metodologia? SI. Su diseño es recomendable seguirlo a través de las directrices básicas de una metodología. Pero su implementación REAL, es decir, una vez que sabemos CUANTAS y QUE clases tenemos y COMO se relacionan, podemos por ejemplo implementar los objetos/clases en ensamblador o embutir ensamblador NATIVO en los METODOS de los objetos si hablamos de C++, o ensamblador para la JVM (Oolong) si hablamos de JAVA, o MSIL para .NET si hablamos de C#, C++ Managed Extensions …..

Asi pues, puedo indicar el uso de las metodologias como algo que ayuda a vivir en un mundo digital más ordenado, pero siempre existirán formas de arrancar rendimiento al procesador, rendimiento sustraido por la existencia de las citadas metodologías.