Regla N° 6: Lo importante es el "Que hace" y no el "Como lo hace"

Tradicionalmente cuando uno estudia programación por primera vez, en la carrera de Informática o afines, por algún motivo desconocido para mi, se comienza estudiando programación estructurada, a veces en pseudocódigo, en Pascal, en C, o quizás en Java, pero orientado de alguna forma estructura. Se ven bonitos diagramas de flujo (Flowchart), donde todo tiene un orden y una secuencia determina. Nos enseñan que un algoritmo es un proceso, pasó a paso, que con una misma entrada, produce una misma salida. Datos entran y datos salen.

Y después cuando ya está adaptado nuestro celebro para hacer las cosas de una determinada manera, ¡Bang!, nos cambian el paradigma a una la programación orientada a objetos, que curiosamente es el paradigma de programación que ofrece mayores virtudes en el desarrollo de software, es mas casi todos los lenguajes modernos de programación vienen con la coletilla "Todo es un objeto", frase que aunque ciertamente relativa, nos hace ver la importancia de este paradigma.

Pero ¡Ay!, todo se ve con el prisma de programación estructurada, incluso se aprende la programación orientada a objetos desde este enfoque, haciendo comparaciones, diferencia y similitudes. Todo esto hace que el aprendizaje este condicionado y limitado por un enfoque previo.

Hagamos un paréntesis en este punto para contar una pequeña anécdota. Hace años, tuve un maestro de historia, que nos comento el gran avance industrial que supuso la creación telar mecánico, que simplifica y automatizaba la creación de tejidos de distintas formas y colores, con lo que se vio una mejora en los tiempos en la fabricación, y una rebaja en su costo. Era como el principio de la industrialización, en la que mejores procesos, y avances se iba incorporando en la vida diaria de la producción de nuevos elementos, desde las mencionadas telas, a la fabricación de coches, hasta la llegada de microprocesadores y computadoras. También nos señalo que seria ridículo, que si exigiera un país en vías de industrialización, comenzara por los telares y continuara implantado poco a poco todos los avances tecnológicos de otros países, como queriendo recorrer su mismo camino, porque este jamás alcanzaría un mismo estatus industrializado (llego tarde a la carrera). La única solución posible seria que comenzara en el mismo punto tecnológico que corresponde a la actualidad, para que ambos pudieran progresar a la par.

Lo mismo pasaría con lo programación, que se quiere enseñar aparentemente en el mismo orden en que evoluciono esta disciplina, (Curiosamente cuando estudie sistemas, nos enseñaron, en este orden, los siguientes lenguajes de programación: Pascal, Fortran, C, Prolog, ADA, C++, Visual Basic 6 y Java, que básicamente fue el orden en que fueron creados, salvo los dos primero).

El problema del enfoque de la programación estructurada es que se enfoque demasiado en la forma de trabaja que tiene las computadores, esto es "Lo importante es como lo hace", ejecutando una por una las líneas de programación de un sistema, y realizando saltos en el flujo según determinadas instrucciones.

Los "humanos", no resolvernos problemas de esta manera, o por lo menos no generalmente, nosotros descomponemos un problema en elementos mas pequeños, a los que podemos catalogar, y les atribuimos características y propiedades, olvidando además aquellas datos y circunstancia que no su útiles para el problema, después generalizamos dichos elementos para que nos sirva en solucionar otra problemas parecidos. Este forma de pensamiento es donde prima "Lo importa es lo que hace", y es uno de los pilares de la programación orientada a Objetos.

En la programación orientada a objetos, se diseñan elementos, donde prima la representación de "Que es lo que hace" y "Que son", principalmente, a través de sus atributos y sus métodos. también se establece como se relacionan con otros tipos de elementos (o clases), ya sea mediante técnicas como la composición, la herencia, o el envió y recepción de mensajes.

De esta forma centrándonos en "Que hace" obtenemos una comprensión mas clara del sistema, y de sus requisitos, además construiremos un sistemas más escalable (debido a que no nos estamos centrando en "Como lo hace"). Inclusive tendremos muchas más posibilidades de conectarnos a otros sistemas, puesto que queda mas claramente establecidos los limites y conectores de estos.

Cuando nos centramos al contrario en "Como lo hace", obtenemos, entre otros, los siguientes problemas:

• Un código lleno de sentencias if, y totalmente ausente de herencia y polimorfismo (la herencia se sustituye con bloques if, que se repiten en cada función).
• Igualmente total falta de Interfaces, que son la máxima expresión del pensamiento "Lo importante es lo que Hace".
• Un código lleno de clases estáticas, con simples métodos expuestos.
• Funciones que en lugar de recibir objetos y trabajar con ellos, recibe una lista indeterminada de parámetros, con tendencia a crecer, uno detrás del otro y con ausencia de sobrecargas.
• Separación de los datos y el negocio del sistema (en la programación orientada a objetos los datos (atributos) y el negocio son indivisibles).
• Clases muy grandes cuyos métodos no tiene ninguna relación.
• Clases muy pequeñas, porque no se tiene claro dónde colocar los métodos, y se crean nuevas clases para albergar pocos métodos.
• Métodos desproporcionados (tanto por grandes, como por pequeños), con excesiva dependencia entre ellos.

Y lo más importante dificultad para modificar y comprender el código.