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.
