Todo es un objeto

1.1 Objetos y clases

Hoy vas a aprender cómo funciona un típico programa en JavaScript. Y la noticia principal: cada programa en JavaScript está compuesto de clases y objetos. JavaScript es un lenguaje orientado a objetos y todo en él son objetos: números, cadenas, funciones e incluso clases.

Entonces, ¿qué son las clases?

Empezaré con una analogía. Imagina que quieres hacer un pequeño barco. Primero necesitas hacer un plano, luego enviarlo a la fábrica, donde construirán el barco según ese plano. O una docena. De hecho, tantos barcos como quieras. Lo importante es que con un solo plano se pueden construir decenas de barcos idénticos.

En la programación en JavaScript todo es exactamente así.

Planos

Un programador es como un diseñador. Solo que el diseñador dibuja planos y el programador de JavaScript escribe clases. Luego, a partir de esos planos se crean partes, y a partir de clases se crean objetos.

Primero escribimos clases (hacemos planos), y luego, durante la ejecución del programa, basándose en esas clases, JavaScript crea objetos. Exactamente como los barcos se crean a partir de planos.

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

O aquí va otra analogía...

Hormiguero

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

El número de hormigas de cada clase es diferente. La reina es una para todo el hormiguero, los guerreros son decenas, y las hormigas obreras son cientos. Tres clases y cientos de objetos. Las hormigas interactúan entre sí, con otras hormigas y con otras clases bajo reglas estrictamente definidas.

Este es simplemente un ejemplo ideal. En un programa típico, todo es exactamente así. Hay un objeto principal que crea objetos de todas las demás clases. Los objetos comienzan a interactuar entre sí y con el 'mundo externo' del programa. Dentro de estos objetos su comportamiento está estrictamente programado.

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 una clase y los objetos de esa clase. La analogía es muy fuerte. El segundo ejemplo (sobre el hormiguero) muestra la relación entre 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 también debes describir su interacción. Suena complicado, pero es más fácil de lo que parece.

En JavaScript todas las entidades durante la ejecución del programa son objetos, y escribir un programa se reduce a describir diferentes maneras de interacción de objetos. Los objetos simplemente llaman métodos de otros y pasan datos necesarios.

Documentación

¿Y cómo saber qué datos pasar a los métodos? Aquí ya todo está pensado por ti.

Normalmente, cada clase tiene una descripción que dice para qué ha sido creada. También, usualmente, cada método público tiene una descripción: qué hace y qué datos necesita recibir.

Para usar una clase, necesitas saber en términos generales qué hace. Y también necesitas saber exactamente qué hace cada uno de sus métodos. Y no es necesario saber cómo lo hace. Es como una varita mágica.

Veamos un código — copiar un archivo:

    
      const fs = require('fs');

      // Abrir archivos
      const src = fs.createReadStream('source.txt');
      const dst = fs.createWriteStream('destination.txt');

      // Copiar contenido de source.txt a destination.txt
      src.pipe(dst);

      // Cerrar archivos después de terminar de copiar
      src.on('end', () => {
        src.close();
        dst.close();
      });
    
  

Si lees este código línea por línea, podrías adivinar qué hace en términos generales. 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 complicado al mismo tiempo. Simple, porque no hay leyes estrictas: todo lo que no está prohibido, está permitido. Y complicado por esta misma razón: hay muchas maneras 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. Y por otro, es importante el argumento, los caracteres de los personajes, las contradicciones internas, los conflictos, el estilo de narración, la intriga, etc.

Lo principal es entender para quién estás escribiendo el código. Y escribes código para otros programadores.

El desarrollo de cualquier producto es la introducción de cambios: agregaron aquí, eliminaron allá, modificaron esto. Y así, con pequeñas iteraciones, nacen grandes, enormes y gigantescos proyectos.

El requisito principal para el código es debe ser comprensible para otros programadores. Un código incorrecto pero comprensible puede ser corregido. Un código correcto pero incomprensible no podrá ser mejorado. Solo quedará tirarlo.

¿Entonces cómo escribir un código bueno y comprensible?

Para esto necesitas hacer tres cosas:

• Escribir buen código y comprensible dentro de los métodos — es lo más fácil
• Decidir qué entidades deben estar en el programa
• Dividir correctamente el programa en partes lógicas

¿Qué hay detrás de estos conceptos?

Escribir buen código dentro de los métodos

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

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

Así está hecho a propósito. JavaScript es uno de los pocos lenguajes donde es fácil escribir código autodocumentado: código que es comprensible sin comentarios. En buen código en JavaScript muchos métodos se leen simplemente como oraciones en inglés.

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

En JavaScript se acostumbra escribir código fácil de leer. Se prefiere que cada método encaje completamente en la pantalla (longitud del método: 20-30 líneas). Esto es una norma para toda la comunidad JavaScript. Si el código se puede mejorar, debe mejorarse.

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, en el momento en que te digas a ti mismo "así está bien", tu desarrollo se detendrá.

Decidir qué entidades deben estar en el programa

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

Excelente, funcional, rápido, código no estándar — es un mal código.

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

Y, por cierto, ya tienes a la mano un excelente, popular, bien documentado proyecto — React. Empieza con eso.

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

Cuando empieces a entender las respuestas a todas estas preguntas, podrás escribir código comprensible para otros.

Sin embargo, quiero advertirte del análisis de código en métodos de D3.js. El código de muchos métodos fue reescrito con el fin de maximizar la velocidad — su legibilidad es cuestionable.

Dividir correctamente el programa en partes lógicas

Cualquier programa generalmente se divide en partes o módulos. Cada parte es responsable de un aspecto del programa.

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

Pero una laptop es un ejemplo de arquitectura monolítica: partes lógicas más o menos hay, pero están más integradas. En un Macbook Pro, para limpiar el teclado, necesitas desmontar la mitad de la laptop. Y si derramas café en la laptop — es motivo para pedir una nueva. Solo no café.

1.3 Creación de tus propias clases

Estás aprendiendo a programar, así que necesitas empezar de a poco — aprender a crear tus propias clases.

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

Lista de entidades

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

Al comenzar a diseñar un programa, simplemente puedes escribir en un papel una lista de entidades (objetos) que deben estar en el programa. Luego, programarlos bajo el principio: cada entidad es una clase separada.

Ejemplo

Supongamos que quieres escribir un juego de ajedrez. Necesitarás entidades como tablero de ajedrez y 6 tipos de piezas. Las piezas se mueven de diferentes maneras, tienen valores diferentes — lógicamente, son clases separadas. Y en realidad, al principio, cuanto más clases — mejor.

Encontrar a un programador principiante que en vez de dos clases hubiera escrito diez es muy raro. Ahora bien, en lugar de diez escribir dos, o incluso una, eso les encanta a los principiantes. Así que más clases, señores programadores. Y tu código será más comprensible para todos, excepto quizás para ti mismo 😛

Ajedrez

Supongamos que decidimos escribir clases para el ajedrez: ¿cómo se verían estas clases?

¿El tablero de ajedrez es simplemente un array de 8 por 8? Es mejor crear una clase separada para él, que internamente mantenga una referencia al array. Entonces en la clase "tablero de ajedrez" podrás agregar muchos métodos útiles, que por ejemplo, verifiquen si una celda está vacía o ocupada.

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