Curso de programacion en python3 : 06 - Uso de modulos, DRY(No te repitas) y ¿orientacion a objetos?

Esta entrada es parte de una serie, puedes ver la primera aquí

El propósito de esta entrada es mostrar que python tiene herramientas que nos facilitan el trabajo y como utilizarlas, estas herramientas son llamadas de distintas formas y existen en todos los lenguajes de programación modernos, C fue el primer lenguaje en tener "módulos" que en realidad eran programas paralelos a el nuestro hasta que C++ nos permitió acoplar esos programas al nuestro por el mecanismo de la instanciación (se define este mecanismo como reservar memoria ram y rellenarla con algo, en este caso ese algo era una clase y se le conoce como objeto una vez tiene almacenado algún dato que antes era tan solo una variable), hasta el momento solo he trabajado usando módulos "fantasma", con esto quiero decir que las cosas propias de python utilizadas en las anteriores entradas son por defecto importadas y se pueden usar sin ningún protocolo, cuando hablamos de paquetes, librerías o como debe decirse en python, módulos, estamos haciendo mención al principio DRY(Don't Repeat Yourself / No Te Repitas), ya que el objetivo de tener objetos es hacer una clase estándar que tenga ciertas funciones y con solo instanciar esta clase seamos capaces de utilizarlas sin reescribir sus funciones, mas allá de esto, casi todo lo indispensable para el funcionamiento de un programa pequeño o mediano ya existirá como parte del lenguaje de programación.

Como estos módulos son miles y ya sabemos que todos nuestros programas pueden ser usados a modo de modulo, lo mejor será reciclar el programa de la clase anterior, vamos a usar ese programa como modulo y de una vez trabajaremos con ciertos conceptos de la orientación a objetos, vamos al código utilizando el segundo programa de la entrada anterior:

/*este codigo se escribe en un archivo llamado imprimir, en caso contrario hay que importar esta clase con el nombre que tiene el archivo*/
#!/usr/local/bin/python3
#coding:utf-8
def salida_programada():
    entrada = input("Desea salir del programa? 1-si 2-no\n")
    try:
        entrada = int(entrada)
    except:
        print("Error en el ingreso")
        return
    if(entrada == 1):
        exit()

def tarea(entrada):
    print("se ha introducido",entrada)

def switch_manual(entrada):#les recuerdo que no hay switch
    if(entrada == "salir"):
        salida_programada()
    else:
        tarea(entrada)
       
if __name__=='__main__':#secretos de la vida :v sigue siendo un metodo
    while(True):#¿es infinito? pues si :v es la gracia
        entrada = input("Ingrese algo para mostrarse o salir para salir\n")
        switch_manual(entrada)


/*Este otro es la implementación del modulo, no importa cual sea su nombre pero si deben estar ambos archivos en el mismo directorio o carpeta para que funcione correctamente*/
#!/usr/local/bin/python3
#coding:utf-8
import impresion #se importa la clase, sustituya impresion por el nombre de su archivo
if __name__=='__main__':
    impresion.tarea("Esto se imprime desde otro modulo")

El modulo no es complejo y creo que no es necesario explicarlo, su objetivo era imprimir lo que el usuario enviara y si no era posible convertirlo a numero entero saltaba un error, ahora bien nos estamos saltando la ejecución al llamarlo desde otro modulo, cuando utilizamos módulos tenemos que decirle al interprete que "impresion" es una dependencia de nuestro script, es decir, impresión es un modulo que se requiere para el funcionamiento del sistema, esto lo hace python de forma invisible pero una vez importados podemos hacer uso de los métodos y variables que este modulo tenga sin estar limitados por su forma de ejecución, hay que tomar en cuenta que seguimos limitados por sus funciones que son la única forma de utilizar el código, entonces sabiendo que el módulo tiene un método que imprime todo lo que entra por parámetro solo nos hace falta enviarle cualquier dato que se pueda imprimir y la magia sucede en ese objeto de la clase impresion, sucede en una instancia creada por el programa que ejecutamos.

Al definir un poco esta forma de trabajar tan útil como lo es la programación orientada a objetos(POO de aquí en adelante), primero quiero ir en defensa de la programación estructurada y funcional, hay cosas tan pequeñas o concretas que solo pueden ser hechos en base a programación funcional, por tanto es error bastante común de estudiantes como yo hacer una solución bastante simple utilizando la POO, cuando un problema se puede resolver sin interfaz gráfica es del dominio de la programación funcional o estructurada, cuando queremos solucionar algo que se extiende mas allá de la consola y requiere mucho código, resulta mejor orientar lo a objetos, hay excepciones, el juego Quake III está escrito en C totalmente y no hay mejor forma de haberlo hecho, esto por que las maquinas de los 90's no eran muy potentes, sobre todo por que era mas rentable vender maquinas recreativas con el juego embebido que vender CD del mismo, los invito a conocer mas de esa historia, el punto es que dependiendo de nuestro conocimiento y los requerimientos del hardware podemos utilizar navajas suizas como C teniendo la posibilidad de medir en bits el gasto de memoria que ejerce nuestro programa o python donde se gasta bastante ram pero casi siempre es lo que sobra en nuestras modernas maquinas, somos programadores, la decisión es nuestra, escoja cada uno con sabiduría y documentación al respecto.

Ahora voy a hablar de java, es posible hacer programación estructurada pero siempre estamos dependiendo de grandes cosas necesarias y complejas de entender que son propias del lenguaje, mas allá de una sintaxis, hablo de una estructura engorrosa que le facilita la vida a los creadores de java, pero es motivo de confusión, python no tiene una estructura limpia, fija y esplendorosa (guiño, guiño, fanáticos de la RAE a mi), sino que prefiere que las cosas pasen al ritmo del programador, el objetivo de este lenguaje es ir de cero a cien, el método main en casi todos los lenguajes con orientación a objetos es obligatorio, aquí resulta totalmente optativo y fue obviado hasta la entrada anterior por que es importante para entender el concepto de método, en C/C++ es obligatorio pero sigue siendo mucho menos complejo que el de java, con imágenes robadas de Internet voy a ejemplificar esto con claridad.

Tomado de una presentación de Mariano Reingart

En orden de derecha a izquierda y de arriba hacia abajo los lenguajes son C, pascal, C++ y java, pascal claramente es estructurada pero simple de comprender, el mas complejo de ver es java, principalmente por que nos saltan muchas dudas complejas de resolver (que son public, class, static, void, String[] args, system, out, println?), en C es bastante mas corto pero hay que importar el paquete stdio.h mientras que no necesitamos nada de eso al iniciar en python, C++ es casi igual que C pero bastante mas intuitivo, creo que esa imagen dice lo suficiente sobre por que decidí enseñar python antes que C/C++, lenguaje que aprendí hace mas tiempo, es muy parecido a java por ser su padre espiritual en muchos aspectos y en el que he trabajado mas horas, en python puedo responder dudas con la velocidad que yo quiera, he querido enseñar rápido pero sin saltarme una sola regla para saber que tan bien era capaz de explicar conceptos complejos y al parecer me ha salido maravillas, tardé casi un año para empezar a cogerle el truco a la orientación a objetos en java y justo ahora ya he revelado algunos misterios complejos de ese paradigma, creo yo que de forma ordenada hasta esta entrada donde me perdí un poco, pensaba que no debería avanzar en orientación a objetos hasta la 7 pero es mas claro utilizar un modulo que ya teníamos a intentar comprender el funcionamiento del modulo y los conceptos propios del paradigma orientado a objetos a la vez.

Es casi natural la orientación a objetos, vamos a usar la imaginación por un momento, ¿que es una silla?, para cualquier persona son 4 patas y una tabla para sentarse, pero según la orientación a objetos hay que hacer una deconstrucción mas grande que esa, una silla son patas tipo entero por que se pueden contar, respaldar que es booleano(por que la silla o lo tiene, o no lo tiene), comodidad es una cadena(para escribir una extensa critica), la silla tiene coordenadas X,Y y Z que la ubican en el espacio, deberá haber un método para cambiar la posición de la silla, el numero de patas, si tiene respaldar e incluso cambiar nuestra critica sobre la comodidad, eso es orientación a objetos, "modelamos" un objeto real usando solo lo indispensable para el desarrollo de nuestra aplicación e ignorando el resto, hay muchas mas características de la silla como el peso o tamaño pero en un juego bastarían esos componentes para definir el comportamiento de la silla como objeto.

Para la próxima entrada voy a conceptualizar la orientación a objetos con imágenes, quiero trabajar en el desarrollo de un programa bastante mas complejo en comparación a todos los anteriores que me sirva al menos para hablar de objetos, en las próximas entradas ya habrá tiempo para hablar sobre herencia y polimorfismo, muy útiles y bastante sutiles, estos conceptos son de potencia indiscutible pero solo aparecen en situaciones muy concretas, pocas veces he podido encontrar un polimorfismo o herencia pero se agradece mucho saber como identificarlos, cuando están presentes no hay otra forma de abordar un problema sin mal gastar memoria.

Siguiente entrada