A vueltas con la programación orientada a objetos

Comienzas a estudiar programación y te cuentan que debes coger un problema a solucionar y dividirlo en varios pasos, divide y vencerás esa es la premisa, y esos pasos los etiquetes con un nombre para acceder más fácilmente a ellos, a esa parte más pequeña se le llama función o procedimiento. El siguiente problema es ¿y donde guardo los datos con los que trabajo? la solución es utilizar pequeños contenedores ubicados en la RAM del ordenador llamados variables, los cuales a groso modo pueden guardar un número, una frase o un valor booleano (verdadero o falso), obviamente cada variable también se la etiqueta con un nombre para tener acceso a ella de manera más sencilla. A esas funciones le puedas dar también una variable para que opere con ella y guarde en esta el resultado de realizar las acciones que almacena. Eso es la programación estructurada.

Pero estoy haciendo una app para mecanizar mi colección de discos y necesito guardar información de ellos y si por cada disco tengo que crear una variable numérica para el año, dos del tipo frase para el nombre del disco y el nombre del grupo apaga y vámonos porque tengo 1000 discos (que fácil es obtener archivos mp3 de la red hoy en día…)… en ese momento entra en escena la customización de variables, el famosisimo tipo “struct“, un tipo de variable que se basa en la combinación de tipos más pequeños, de ese modo creo mi tipo struct llamado TDisco el cual formo con la variable del tipo número año, la variable de tipo frase grupo y la variable de tipo título, esto unido a mi colección de procedimientos (o como se define formalmente librerías) para guardar un TDisco en el listado de discos, buscar un TDisco en mi listado, etc me resuelven el problema que tenia al principio: TENER MI COLECCIÓN DE DISCOS ORDENADA.

¿Y ahora que? ya se programar ¿no? ¿cual es el next level? pues el next level amigo@ mi@ es poesía, es esa parte de la informática que te dará la oportunidad de ser creativo cuando la domines, porque no es fácil dominarla.

Te dirán que hay una cosa llamada “clase” que debes “instanciar“… pero tu solo verás que “esa” clase no es más que un struct al que se le han vinculado procedimientos, ahora llamados “métodos“, y que instanciar es almacenar en memoria un variable de ese tipo… nada nuevo sobre el horizonte. Pero pasarán los años, programarás con lenguajes orientados a objetos porque ya nadie programa a la vieja usanza y poco a poco asimilarás los conceptos, te darás cuenta que lo que defines como clase es mucho más que unas cuantas variables y procedimientos, es el ADN de una entidad que será única cuando se cree en memoria, la cual durante su vida pasará por diversos estados y reaccionará según su programación ante estímulos exteriores.

Ahora cuando reprogramas tu vieja app según la P.O.O. puedes preguntar directamente a un disco de que año es ejecutando su método “dameElAñoDeGrabacion“, puedes llamar al método “guardaDisco” del objeto estantería pasandole un objeto disco junto a la llamada, tan cercano a la forma en la que interactuamos nosotros con el mundo que nos rodea. Dejas de ver variables en memoria almacenadas y comienzas a ver entidades que se relacionan las unas con las otras, divides un problema, no en pasos, sino en elementos con distintas reglas de interacción con el resto. Ocultas la parte de tu programación que no necesitan conocer los que trabajen en un futuro con tus clases dejando a la vista solo la interfaz de usuario, del mismo modo que un coche tiene un volante y solo necesitas saber que girándolo el coche cambia de dirección sin necesitar conocer que elementos intervienen en el movimiento del eje de las ruedas.

En ese momento el desarrollador pasa a ser una persona creativa, pasa a visualizar la solución de un problema como la suma de elementos que trabajarán al unísono para solucionarlo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *