INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS

LA ROCA AGRESTE, FARALLONES Y LA MAR BRAVÍA DE ANAGA, COSTA NORESTE DE TENERIFE.

      ¡POR FIN INICIAMOS NUESTRA APROXIMACIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS!

      Pero antes de empezar, si me lo permitís, me gustaría dejar aquí unas pequeñas consideraciones previas. No quisiera extenderme mucho, pero creo que es de justicia empapar este lienzo en blanco con algunas palabras en negro, mayormente, porque el corazón me lo pide.

Como mis padres me enseñaron que es de bien nacido ser agradecido, os quiero dar a todos vosotros que habéis dedicado un momentito de vuestra vida a echarle un vistazo a este blog nuestro y, aún más, tenerlo en cuenta y consultarlo de vez en cuando , mi más sincero agradecimiento (y el de mis peludos colaboradores, claro): ¡MUCHÍSIMAS GRACIAS!

Cuando empecé a elaborar este manual de aprendizaje sobre Python, como casi todo el mundo que inicia un cuaderno de bitácora virtual sobre cualquier tema que le interese, alberga alguna expectativa sobre que la visualización de su trabajo alcance, al menos, a un puñado de personas y, sobre todo, que les sirva para algo: aprender, entretenerse, disfrutar de los contenidos, reflexionar, impulsar y encauzar vocaciones, etc.

Yo no sé a ciencia cierta si este blog nuestro os ha servido para aprender y/o aumentar y enriquecer vuestro conocimiento previo sobre el lenguaje, pero sí sé que, al día de hoy, sois un buen puñado de AMIGOS (espero que me permitáis consideraros así) los que me habéis hecho el inmenso favor de confiar en este manual virtual. 

Espero y deseo no haberos defraudado. De nuevo: GRACIAS.

Y es precisamente el número de visitas lo que me ha llevado a tomar la decisión de compaginar el desarrollo de la Programación Orientada a Objetos, que comenzamos a partir de aquí, con la adición de algunas páginas y entradas más que aún quedan para concluir la parte básica de nuestro manual, es decir, que al mismo tiempo que subiré material para la Programación Orientada a Objetos, continuaré subiendo material para la parte básica del mismo 👍.

Además, a título personal, considero que nuestro blog debe estar en continua evolución y en continua autocorrección. ¿Qué significa esto? Que una vez que haya publicado una página o una entrada, ésta no queda definitivamente cerrada. ¡NO! A fecha de hoy, y para quienes hayáis seguido o visitado una o varias páginas/entradas de este manual os invito a que las VOLVÁIS A CONSULTAR pues es posible que haya añadido información nueva, nuevos ejemplos, mejorado las explicaciones, añadido referencias y/o incluido pequeños "chispazos" que son como diminutos scripts que consiguen resolvernos con notable sencillez algunas cuestiones con las que podamos toparnos como programadores, pequeños "trucos", en síntesis, vinculados directamente al tema que se desarrolla en la página/entrada. Lo podéis identificar con este símbolo:

Aquí os dejo una muestra tomada de la entrada  T1. LOS OPERADORES 'IN' E 'IS'. PERTENENCIA E IDENTIDAD.:

Hechas esta consideraciones necesarias, y después de agradeceros vuestra paciencia por la lectura de la entradilla, vayamos al tajo.

Lo primero, como no puede ser menos, para ir haciéndonos una idea del berenjenal donde nos vamos a meter, comenzamos por una introducción al concepto de Programación Orientada a Objetos, en adelante, POO, por sus siglas en español. La POO constituye un paradigma de programación moderno, muy actual, una forma específica, concreta, de programar, basada en la construcción y uso de una "unidades básicas" de código denominadas objetos (objects) que, en el ámbito particular de este paradigma, también se conoce como  instancia de clase o, abreviando, instancia (instance): o sea, objeto = instancia.

Recordemos que para Python casi todo cuanto existe en el mundo, casi todo cuanto Dios ha creado, es un objeto. Y, ... claro, claro, por ahí van los tiros: esto significa que desde su estructura más íntima Python nació enfocado hacia la POO aunque, como ya hemos mencionado en los capítulos anteriores, Python es, en realidad un lenguaje de programación MULTIPARADIGMA, que se desenvuelve igual de bien en la programación funcional, imperativa y, lo que nos interesa a nosotros, orientada a objetos, con la bendita singularidad de que es capaz de combinarlos todos en un mismo código 🙌.

La filosofía que envuelve este concepto se asienta en que nuestra forma de programar se asimile lo más posible a la forma natural  en que las personas nos relacionamos con el mundo, nuestra forma especial (de especie) de comprender, interpretar y expresar la realidad, lo que nos sitúa en lenguajes de alto nivel, como es el caso de Python, a la par que nos aleja de los procedimientos oneroso, reiterativos  y artificiales del código máquina, cediéndole las labores de traducción/mediación entre nosotros y el core del lenguaje al famoso intérprete (de Python), que para eso está.

Esta forma de hacer las cosas, por supuesto, tiene sus beneficios, siendo el principal de todos ellos es que nos ayuda a reducir esfuerzos, permitiendo que el código generado por un programador sea perfectamente reconocible y reutilizable por otros programadores, en base a las normas comunes, incidiendo en la reusabilidad del código. Un ejemplo: los frameworks, tan importantes, útiles y socorridos en la programación actual.

Concretando un poco más, se trata de deconstruir un problema complejo en estructuras o partes más simples, de tal modo que dividiendo un problema complejo en otros más simples y, por consiguiente, más fácil de resolver individualmente, tendremos que la resolución secuencial de todos y cada uno de ellos supone la resolución per sé del problema original.

De igual manera, todo programa que se nos antoje difícil y enrevesado es susceptible de subdividirse en programas más simples (donde ellos mismos y sus devoluciones son objetos). La resolución de cada uno de estos por separado y la explicitación de la relación que se establece entre cada una de las partes determinan, a su vez, la construcción misma del programa original.

Qué duda cabe que proceder de esta manera hace que el acto de programar se convierta en una tarea más sencilla, se dinamiza y optimiza mejor el proceso de programación y, a la vez, simplifica el código.

Cada una de la diferente tareas o procedimientos independientes entre sí en que se puede subdividir un programa se denomina, como acabamos de decir, objeto. Cada uno de estos objetos resuelve su propia parcela del programa, atiende a su propio ámbito, resolviendo en conjunto (en modo acumulativo: la resolución del primero puede ayudar a resolver el segundo o devolver un dato necesario para su resolución, la resolución del segundo puede ayudar a resolver el tercero o devolver un dato necesario para su resolución, y así sucesivamente.terminando así por solucionar el todo más amplio y complejo que es nuestro proyecto de programa inicial

Este proceso MODULAR (sí: los módulos de Python) de programación permite atender de forma individual cada programa que creemos, reutilizar sus partes, optimizarlas y/o modificarlas, para mejorar el todo (programa) redundando en su beneficio o, reutilizarlas en otros programas distintos que construyamos más adelante.

Así, un objeto puede entenderse también, en un sentido más amplio, como un módulo (parte) de un modelo de organización de un programa susceptible de subdividirse en diferentes porciones.

Acabamos de definir la forma de proceder en la POO por atonomasia para diseñar un programa complejo. A continuación vamos a ver qué es eso de equiparar la programación a vida real, a la "naturalidad", como quien dice, de forma más concreta.

CABECERA DEL BARRANCO DE SAN ANDRÉS DESDE EL CRUCE HACIA TAGANANA, SUR DEL MACIZO DE ANAGA, TENERIFE.

Dicho lo anterior, vamos a mostrar un ejemplo de cómo tenemos que "pensar" desde la perspectiva de la POO. Veremos que resulta muy sencillo, rebosante de sentido común, extraordinariamente similar a como lo hacemos habitualmente en la vida real.

Con la foto de arriba, lo que queremos decir es que desde el punto de vista de la realidad, una "cosa" es un objeto (y, como en el caso del ejemplo, hay objetos diferentes entre sí pero que entendemos que pertenecen a un mismo grupo, concepto o idea, al margen de su apariencia), con unas características concretas que los diferencian del resto de objetos que en el Universo hay, con unas acciones que son capaces de hacer y ejecutar, bien de manera autónoma o con ayuda de otros objetos, y que, normalmente, sirven para algo o tiene alguna utilidad.

Con esta idea en la cabeza, vamos a concretar.

Nos vamos a imaginar un coche (para continuar con la tradición del modelo más socorrido en casi todos los sitios para explicar esto de la POO). Sí: un coche. El que queramos. Un coche cualquiera. Pues bien: vamos a "modelizar" (quedémonos con esta palabreja porque forma parte del vocabulario propio de la POO) esta idea que tenemos de coche para ajustarla a los parámetros de la Programación Orientada a Objetos.

Un coche es un objeto, ¿no? Como una silla, una mesa, un armario ropero de ocho puertas, una batidora, un portaaviones de la VI flota de los USA, un jarrón de porcelana , un smartwatch, un monopatín, un tetrabrick de leche desnatada, la nevera en la que la guardamos una vez abierta, el horno o el microondas donde la calentamos, el vaso en el que nos la bebemos, etc.

Para la Programación Orientada a Objetos y, por ende, para Python, todo lo anterior y más y, por supuesto, el coche mismo, es un objeto.

Pero todos los objetos que se nos puedan ocurrir, por el mero hecho de existir y ser perceptibles por nuestros sentidos, cuentan con DOS cualidades que los definen: tienen  características, propiamente dichas, distinguibles por nuestros sentidos (color, que podemos ver; forma; que podemos ver; sonidos, que podemos oír; olor, que podemos olfatear; superficie, que podemos tocar; etc. Así, los objetos son verdes, amarillos, grandes, pequeños, animados, estáticos, redondos, cuadrados, altos, bajos, largos, anchos, melodiosos, estridentes, olorosos, tienen puertas, ventanas, madera, cristal, metal, teclas, faros, bombillas, etc.) y funcionalidades, es decir, cosas que pueden hacer (o no, como los objetos decorativos que, lo más que hacen, a parte de condenarnos a pasarles el paño del polvo cada dos por tres, como mucho, le dan glamour a la mesilla del comedor) por sí mismos o en combinación con otros objetos, esto es, "hacen cosas". Solemos referirlos como verbos en infinitivo: andar, correr, transportar, iluminar, escribir, volar, saltar, comer, bailar, etc.

AMANECE SOBRE EL PERFIL DE TENERIFE VISTA DESDE LA ISLA DE LA GOMERA.

De  la misma manera, en la Programación Orientada a Objetos también todo objeto existente tiene DOS cualidades que lo definen: sus características, que en la POO se denominan  atributos o propiedades, y sus funcionalidades, lo que pueden hacer, y que en la POO se denominan métodos, el alter ego de las funciones de toda la vida que hemos estudiado aquí, tanto las built-in como, sobre todo, las definidas por nosotros mismos.

      PODEMOS DECIR, PUES, QUE UN objeto EN LA PROGRAMACIÓN ORIENTADA A OBJETOS SE DEFINE POR SUS propiedades, ESTO ES, POR SUS CARACTERÍSTICAS EN UNA ANALOGÍA CON EL MUNDO REAL, Y POR SUS métodos, ESTO ES, POR SUS FUNCIONALIDADES, REALES O POTENCIALES, POR AQUÉLLO QUE SON CAPACES DE HACER. 

Con estos conceptos en mente procedamos a ilustrar este proceso en nuestro objeto coche. ¿Cuáles serían las características ≃ propiedades del objeto coche? Pues, por ejemplo, la marca, el modelo, el color, el tipo de combustible que utiliza, el año de fabricación, el caballaje, la matrícula, etc. Muy bien. ¿Y cuáles serían sus funcionalidades ≃ métodos? Pues, por ejemplo, circular por la carretera, frenar, acelerar, cambiar de dirección, encender los faros, bajar las ventanillas, mover las escobillas del parabrisas, estacionar, transportar, etc.

Obviamente, a cada propiedad le corresponde un valor. Si nuestro objeto coche tiene la propiedad "color", hombre, de algún color tendrá que ser: blanco, rojo, gris, negro, azul, etc.; si tiene la propiedad "marca", de alguna firma de fabricante de automóviles tendrá que ser: Seat, Renault, Peugeot, Honda, Opel, Lancia, Chrysler, Aston Martin, etc.; si tiene matrícula, alguna leyenda deberá lucir inscrita en la placa: eu 3343 f, gh 456sk, 7p zz 232, 1246 ggj, etc.

Veamos una esquematización:

Estos objetos que hayamos creado con sus propiedades o atributos y sus respectivos valores más su métodos asociados nos resultarán útiles en aquéllos programas que puedan (o deban) hacer uso de ellos: el objeto coche nos vendrá como anillo al dedo para construir un módulo sobre "mecánica del automóvil", "gestión de talleres de automoción", "gestión de flotas de vehículos de alquiler", "parque móvil del municipio *", "anuario internacional de marcas y modelos de vehículos 2020", etc.

Veamos un desarrollo similar al de la fotografía superior par un objeto completamente distinto y tomar así consciencia de la idea:

De modo análogo, un objeto átomo de carbono, con sus propiedades (valencia, peso atómico, masa, etc.), con sus valores correspondientes, y sus métodos (enlaces, estructuración, reactividad, etc.) nos sería muy útil también en un programa de "química orgánica", "compuestos hidrocarburados" o "plásticos biodegradables" entre otros. O, para continuar con los ejemplos, un objeto bolígrafo, con sus propiedades (modelo, marca, tipo de punta, diámetro de la esférula, tinta, color, etc.) y métodos (escribir, dibujar, subrayar, puntear, etc.) nos resultaría interesantísimo en un programa de "edición de texto", "edición de dibujo a pluma", "expresiones caligráficas", "perfilador grafológico", etc.

      

      YA HEMOS DICHO EN MULTITUD DE OCASIONES QUE PARA PYTHON, TODO CUANTO EXISTE E, INCLUSO, TODO CUANTO PUDIERA LLEGAR A EXISTIR ALGUNA VEZ, SON objetos (objects). PUES BIEN, INCLUSO HASTA LOS PROPIOS MÓDULOS Y PROGRAMAS QUE HEMOS MENCIONADO ("gestión de talleres de automoción", "química orgánica", "compuestos hidrocarburados", "edición de dibujo a pluma", ETC. SON, A SU VEZ, objetos PYTHON DE PLENO DERECHO. POR CIERTO, LO QUE HEMOS EXPLICADO HASTA AHORA NO PARECE MUY DIFÍCIL DE ENTENDER, ¿VERDAD? A MÍ CASI NO ME CUESTA NADA...

Finalizamos esta parte de la introducción a la Programación Orientada a Objetos haciendo hincapié en que este moderno paradigma de la programación se desarrolla de acuerdo al marco de trabajo o estructura de procesos que mencionamos al principio, recordemos, desestructuración de programas complejos en programas más simples apoyándonos en la modularización, en estrecha unión con la caracterización de los objetos como entidades que tienen características y funcionalidades que los definen y singularizan. 

CHUMBERAS O NOPALES CON SU FRUTO, EN CUALQUIER PARTE DE TENERIFE.

Concretando aún más, vamos a centrarnos ahora en el concepto de CLASE (class, en inglés) aunque ahondaremos con mayor profundidad en él en la página siguiente. Una CLASE, class a partir de ahora, es una especie de objeto matriz que contiene, a su vez, otros objetos que derivan de ella y relacionados entre sí. Podemos entender una class como un superobjeto del que emana todos los demás, como un mismo y único nubarrón gris del que caen todas las gotas de lluvia que repican en nuestra ventana. De hecho, la POO construye en Python un nuevo tipo de dato (como int, str, list o dict, por ejemplo): el tipo class.
Este nuevo tipo de dato contiene dos elementos principales:

• Uno o más datos del tipo que sean y que representan propiedades/atributos del objeto. 
• Una o más funciones que son las encargadas de operar sobre los primeros o sobre otros datos distintos, es decir, los métodos.

Vamos a verlo con un ejemplo. Tenemos un objeto coche que, como ya hemos visto, presenta unas propiedades y métodos particulares. ¿De acuerdo? Sin embargo, muchas de estas mismas propiedades y métodos, serían también representativos de un objeto motocicleta o de un objeto camión.

Podríamos aglutinar sus propiedades y métodos comunes (todos tienen color, tienen marca, responden a un modelo, tienen ruedas, circulan, transportan, frenan, aceleran, etc.) y endosársela a un superobjeto que los contengan. Podríamos llamar a este superobjeto o class como automóvil, de tal modo que la class automóvil recogiera propiedades y métodos que sus objetos-hijos o derivados (coche, motocicleta, camión, etc.) compartieran. Después, cada objeto-hijo o derivado contaría con propiedades y métodos específicos que los diferencian unos de otros.

A este proceso de "construir" un objeto a partir de una class se llama instanciación, del inglés, instance,  (instanciar un objeto).

Así pues, el objeto automóvil se convierte en class y, a partir de ella, podemos instanciar ("crear", "construir", son sinónimos de instanciar) distintos objetos como coche, motocicleta, camión, que compartirán entre sí las propiedades y métodos de la class de la que derivan, pero donde cada uno de ellos contará con propiedades y métodos propios que los diferencian entre sí.

Por así decirlo, un objeto instanciado es una variable: las variables del tipo class se llaman objetos, object en inglés.

A partir de todo esto se infieren conceptos como jerarquía, herencia, polimorfismo, etc. que configura el universo de la Programación Orientada a Objetos. No los vamos a traer aquí, a esta sencilla aproximación. Ya los iremos conociendo conforme avancemos juntos por este ecosistema.

Un detalle final que nos recuerda el modo de gestionar la memoria que practica Python: si creamos (instanciamos)  un objeto de nombre X a partir de una class, y le aplicamos métodos instanciados en ella, ejecutará las acciones correspondientes. Pero si dentro de la misma class decidimos instanciar un objeto nuevo con el mismo nombre X, el objeto X anterior, el original, vamos, deja de existir, se vacía su espacio de memoria, y a partir de entonces sólo existe para Python el nuevo objeto X que acabamos de instanciar. Sin embargo, los resultados de aquellas acciones realizadas por el objeto X original no desaparecen, no se borran: permanecen ahí, tal cual, a la espera de que decidamos qué hacer con ellos, si los revertimos (con nuevo código) o las dejamos tal y como están, bien porque al final nos resulten útiles o porque ya no tengan incidencia en el desarrollo de nuestro programa (en este último caso, convendría también, eliminarlos). ⤐ Si esta situación ya nos puede ocasionar problemas en un script normal y corriente, de los de andar por casa, imaginemos lo perjudicial que puede resultar en un programa amplio o en un programa gráfico.

Aquí terminamos esta larga introducción. Así que arremanguémonos, calémonos el casco de obra y pongámonos los cinturones, que comenzamos a partir de aquí un nuevo nivel en nuestro manual de Python. ¡Ánimo y a por todas! 💪

PIÑA. FRUTO DE NUESTRO PINO CANARIO, PINUS CANARIENSIS, UBICUO EN LOS SUELOS TERMÓFILOS POR TODA LA GEOGRAFÍA DE TENERIFE, DESDE LOS TRESCIENTOS METROS DE ALTURA HASTA CASI LOS TRES MIL.