Todo es un objeto

1.1 Objetos y clases

Hoy vas a aprender cómo se estructura un programa típico en Python. Y la gran noticia es: cada programa en Python se compone de clases y objetos. Python es un lenguaje orientado a objetos, y todo en él son objetos: números, cadenas, funciones e incluso las clases son objetos.

Entonces, ¿qué son las clases?

Comenzaré con una analogía. Imagina que quieres construir un pequeño barco. Primero necesitas hacer un plano, luego llevarlo a la fábrica, donde construirán el barco siguiendo ese plano. O una docena de barcos. De hecho, tantos barcos como quieras. De un solo plano se construyen decenas de barcos idénticos, eso es lo importante.

En la programación con Python todo es exactamente igual.

Planos

El programador es como un diseñador. Solo que el diseñador dibuja planos, y el programador de Python escribe clases. Luego, a partir de los planos se crean piezas, y a partir de las clases, se crean objetos.

Primero escribimos clases (hacemos planos), luego, durante la ejecución del programa, Python crea objetos basados en esas clases. Exactamente como los barcos se crean basados en planos.

Un plano es único, pero puede haber muchos barcos. Los barcos son diferentes, tienen diferentes nombres, transportan diferentes cargas. Pero son muy parecidos: son todos barcos con construcción idéntica y pueden realizar tareas similares.

Otra analogía sería...

Un hormiguero

Un hormiguero es un buen ejemplo de la interacción de objetos. En el hormiguero más simple hay tres clases de hormigas: la reina, los guerreros y las hormigas obreras.

La cantidad de hormigas de cada clase es diferente. Una reina para todo el hormiguero, decenas de guerreros y cientos de hormigas obreras. Tres clases y cientos de objetos. Las hormigas interactúan entre sí, con otras hormigas de su clase y de otras clases, siguiendo reglas estrictamente definidas.

Es un ejemplo perfecto. En un programa típico, todo es exactamente igual. Hay un objeto principal que crea objetos de todas las demás clases. Los objetos comienzan a interactuar entre sí y con el "mundo exterior" del programa. Dentro de estos objetos, su comportamiento está programado rígidamente.

Estas dos explicaciones son dos caras de la misma moneda. La verdad está en el medio. El primer ejemplo (sobre el plano y los barcos) muestra la relación entre la clase y los objetos de esa clase. La analogía es realmente poderosa. El segundo ejemplo (sobre el hormiguero) muestra la relación entre los objetos que existen durante la ejecución del programa y las clases escritas.

Primero debes escribir clases para todos los objetos existentes en el programa, y luego describir sus interacciones. Suena complicado, pero es más simple de lo que parece.

En Python, todas las entidades durante la ejecución del programa son objetos, y escribir un programa se reduce a describir varias formas de interacción entre objetos. Los objetos simplemente llaman métodos entre sí y pasan los datos necesarios.

Documentación

¿Y cómo saber qué datos pasar a los métodos? Eso ya está pensado para ti.

Por lo general, cada clase tiene una descripción que indica para qué fue creada. También, por lo general, cada método público tiene una descripción: qué hace y qué datos necesita recibir.

Para usar una clase, necesitas saber en general lo que hace. Y también necesitas saber exactamente lo que hace cada uno de sus métodos. No es necesario saber cómo lo hace. Una especie de varita mágica.

Miremos el código — copia de un archivo:

src = open('source.txt', 'r')
dst = open('destination.txt', 'w')
            
for line in src:
    dst.write(line)
            
src.close()
dst.close()
        

Si lees este código línea por línea, puedes deducir qué hace en general. Aunque aquí se necesita experiencia y práctica. Así que después de un tiempo este código te parecerá familiar y comprensible.

1.2. Diseño del programa

Diseñar un programa es todo un arte. Es simple y complejo al mismo tiempo. Simple, porque no hay leyes estrictas: todo lo que no está prohibido está permitido. Y complicado también por esa razón: hay muchas formas de hacer algo, y no es fácil encontrar la mejor.

Diseñar un programa es como escribir un libro. Por un lado, simplemente escribes letras, palabras, oraciones. Por otro lado, importan la trama, los caracteres, las contradicciones internas, los conflictos, el estilo narrativo, la intriga, etc.

Lo importante es comprender para quién escribes el código. Recuerda que tu código está destinado a otros programadores.

El desarrollo de cualquier producto implica hacer cambios: agregar aquí, eliminar allá, rehacer esto. Y así, con pequeñas iteraciones, nacen grandes, enormes y gigantescos proyectos.

El principal requisito para el código es que sea comprensible para otros programadores. Un código incorrecto pero comprensible puede corregirse. Un código correcto e incomprensible no tiene solución. Solo queda descartarlo.

Entonces, ¿cómo escribir un buen código comprensible?

Para eso necesitas hacer tres cosas:

• Escribir buen código comprensible dentro de los métodos: lo más sencillo.
• Decidir qué entidades deben estar en el programa.
• Dividir correctamente el programa en partes lógicas.

¿Qué significan estos conceptos?

Escribir buen código dentro de los métodos

Si tienes al menos un nivel básico de inglés, quizás hayas notado lo fácil que a veces se lee el código: como oraciones en inglés:

• class Cat(Pet) – clase Gato extiende la clase Mascota.
• while stream: – mientras el flujo no esté vacío ...
• a if a < b else b – si a es menor que b, devuelve a, de lo contrario devuelve b.

Está hecho así intencionalmente. Python es uno de los pocos lenguajes donde es fácil escribir código autodocumentado: código que se entiende sin comentarios. En buen código Python, muchos métodos se leen simplemente como oraciones en inglés.

Tu objetivo al escribir código es hacerlo lo más simple y conciso posible. Simplemente piensa en qué tan fácil será leer tu código y comenzarás a avanzar en la dirección correcta.

En Python, es costumbre escribir código fácil de leer. Lo ideal es que cada método se ajuste por completo a la pantalla (la longitud del método es de 20-30 líneas). Eso es lo normal para toda la comunidad Python. Si se puede mejorar el código, se debe mejorar.

La mejor manera de aprender a escribir buen código es la práctica constante. Escribe mucho código, estudia el código de otros, pide a colegas más experimentados que revisen tu código. Y recuerda que en el momento en que te digas a ti mismo "esto servirá", tu crecimiento se detendrá.

Decidir qué entidades deben estar en el programa

Necesitas escribir código comprensible para otros programadores. Si 9 de 10 programadores al diseñar un programa crean clases A, B y C, entonces tú también necesitas hacer en tu programa clases A, B y C. Debes escribir código comprensible para los demás.

Un código excelente, funcional, rápido y no convencional es un mal código.

Necesitas estudiar proyectos ajenos: es la mejor, más rápida y más fácil manera de adquirir toda la sabiduría que durante décadas se ha acumulado en la industria TI.

Y, por cierto, ya tienes a mano un proyecto excelente, popular y bien documentado — Python SDK. Empieza con él.

Descompón las clases y estructuras de clases. Piensa por qué unos métodos son estáticos y otros no. Por qué los métodos tienen esos parámetros y no otros. Por qué esos métodos en particular, por qué las clases se llaman así y están en esos paquetes.

Cuando empieces a comprender las respuestas a todas estas preguntas, podrás escribir código comprensible para los demás.

Sin embargo, quiero advertirte sobre el análisis del código en los métodos de Python SDK. El código de muchos métodos ha sido reescrito con el objetivo de maximizar la velocidad de trabajo — su legibilidad está en entredicho.

Dividir correctamente el programa en partes lógicas

Cualquier programa generalmente se divide en partes o módulos. Cada parte se encarga de su propio aspecto del programa.

Como cuando en una computadora hay una unidad central, un monitor, un teclado, y son todas partes separadas y poco dependientes. Además, su interacción está estandarizada: USB, HDMI, etc. Así que si derramas café sobre el teclado, puedes simplemente lavarlo bajo el grifo, secarlo y seguir usándolo.

En cambio, una laptop es un ejemplo de arquitectura monolítica: las partes lógicas están ahí, pero están mucho más integradas. En el Macbook Pro, para limpiar el teclado, tienes que desmontar medio portátil. Y si derramas café sobre una laptop, es motivo para pedir una nueva. Solo no el café.

1.3 Creación de tus propias clases

Cuando recién empiezas a programar, es importante comenzar de a poco — aprender a crear tus propias clases.

Claro que ya las has creado, pero necesitas aprender a entender qué clases deben estar en el programa, cómo deberían llamarse, qué métodos deberían tener. Y cómo deberían interactuar entre sí.

Lista de entidades

Si no sabes por dónde comenzar, empieza desde el principio.

Al principio del diseño del programa, puedes simplemente escribir en una hoja una lista de entidades (objetos) que deben estar en el programa. Luego prográmalos según este principio: cada entidad es una clase separada.

Ejemplo

Supongamos que quieres escribir un juego de ajedrez. Necesitarás las siguientes entidades: tablero de ajedrez y 6 tipos de piezas. Las piezas se mueven de diferentes maneras, tienen diferentes valores — es lógico que sean clases separadas. Por lo general, al principio, cuanto más clases, mejor.

Encontrar a un programador principiante que en lugar de dos clases escriba diez es una rareza. Pero escribir dos en lugar de diez, o incluso una — eso es algo que a los principiantes les gusta. Así que más clases, señores programadores. Y tu código será más comprensible para todos, excepto quizás para ti 😛

Ajedrez

Supongamos que decidimos escribir clases para el ajedrez: ¿cómo lucirían esas clases?

¿Es el tablero de ajedrez simplemente un array de 8x8? Mejor haz una clase separada para él, que internamente almacene un enlace al array. Así, en la clase "tablero de ajedrez" podrás agregar muchos métodos útiles que, por ejemplo, verifiquen si una casilla está vacía o ocupada.

En general, al principio siempre puedes guiarte por el principio: El Programa tiene diferentes Entidades, y cada Entidad tiene un tipo. Ese tipo es la clase.