Teoría: Un poco sobre el lugar y la comprensión de la POO en la programación

¿Qué es la POO? La respuesta que seguramente encontrarás en Internet primero será: herencia, polimorfismo y encapsulamiento. Si profundizas un poco más, además de estos conceptos, aparecerán "envío de mensajes", "clase", "clase abstracta", "prototipos", "interfaces", "despacho", "mixins", "protocolo", "multimétodos" (¡y cientos de otras palabras aterradoras!). Además, cada lenguaje tiene su propio conjunto de entidades que solo se encuentran en ese lenguaje o en lenguajes similares. Y cada uno afirmará que la POO no es POO sin estos conceptos.

Una búsqueda más exhaustiva mostrará que hay muchos artículos en la web sobre "no entiendo la POO" (en estos artículos siempre culpan al autor de no haberlo entendido) o preguntas sobre "cómo entender la POO". Debajo de estos artículos, generalmente hay cientos de comentarios donde siempre se desarrollan acalorados debates sobre la esencia de la POO. Entre estas discusiones, seguramente aparecerán personas que dirán que JavaScript no es un lenguaje orientado a objetos, que no hay POO sin clases, y alguien dirá que los únicos lenguajes orientados a objetos son Smalltalk y Lisp.

Y la guinda del pastel es el flujo continuo de artículos del tipo "POO para principiantes", que intentan explicar la POO utilizando ejemplos de animales (o barcos, coches, cualquier cosa del mundo real), creando una falsa ilusión en los programadores de que han entendido de qué se trata. Y luego estos programadores abren el código y encuentran adaptadores de bases de datos y nada del mundo real.

¿Quién es el culpable y qué hacer?

La POO tiene una historia larga y complicada. Este término fue acuñado por Alan Kay a finales de los años setenta, cuando trabajaba en el lenguaje Smalltalk.

Esto es lo que dijo al respecto:

Para mí, la POO es mensajes, retención y protección local, ocultamiento de estado y enlace tardío de todo. Esto se puede hacer en Smalltalk y en LISP.

Consideraba a los objetos como células biológicas o computadoras individuales en una red que solo pueden comunicarse a través de mensajes.

Curiosamente, de alguna manera predijo Internet

Luego apareció el lenguaje C++, basado en el cual se creó el libro "Análisis Orientado a Objetos". En este libro, Grady Booch, el creador de UML, describió los mismos "polimorfismo, herencia y encapsulamiento". C++ se convirtió en el estándar y todos los "lenguajes orientados a objetos" posteriores lo copiaron.

Cuando le preguntaron a Alan sobre la POO en C++, dijo lo siguiente:

Cuando inventé la POO, no tenía en mente a C++

Desde entonces ha pasado mucho tiempo. La comprensión moderna (no significa que sea la mejor, es solo el estado actual) de la POO es increíblemente diferente de lo que Alan Kay tenía en mente. Esto no significa que sus ideas hayan muerto. Siguen vivas, pero a veces en diferentes formas y en un nivel diferente. Aunque algunos desarrolladores siguen insistiendo en que la verdadera POO es la POO de Alan, todo lo demás no es real. No nos detendremos en esto en detalle. Lo más importante es recordar que cuando los programadores comienzan a hablar sobre la POO, es muy importante entender de qué POO están hablando, de lo contrario surgirán disputas e incluso conflictos. La POO es un tema "religioso".

La POO moderna no es una teoría estrictamente fundamentada, a diferencia de la programación funcional o automática. Es un gran conjunto de enfoques diversos para organizar el código y las entidades (clases, objetos, etc.), que a veces difieren tanto en diferentes lenguajes que conducen a situaciones sorprendentes. Los programadores de PHP se horrorizan con lo que se llama POO en Ruby. Los creadores de Ruby, por su parte, dicen que Ruby es un lenguaje de POO "real", porque "todo es un objeto" en Ruby. Los desarrolladores de Java nunca creerán que la POO está presente en JavaScript.

En esta situación, es muy importante eliminar lo innecesario y encontrar las cosas sin las cuales no se puede llamar a un programa orientado a objetos. Como dicen los matemáticos, encontrar una base (el conjunto mínimo de elementos del cual se pueden derivar todos los demás).

A la POO se le atribuyen muchas cosas que existían y siguen existiendo sin la POO en muchos lenguajes. Por lo tanto, cuando escuches sobre las ventajas de la POO, no tomes esas palabras como verdaderas. Estas ventajas, por lo general, son ventajas solo porque en ese lenguaje es más difícil o imposible hacerlo de otra manera. Siempre puedes encontrar un lenguaje en el que estas mismas ideas estén resueltas de manera muy elegante y eficiente, pero sin clases y objetos.

Por qué aprender POO entonces? Precisamente este enfoque se ha vuelto dominante en los lenguajes populares. En JS, afortunadamente, hay una fuerte multiparadigmatismo (es decir, se puede escribir en diferentes estilos). Es decir, los programas en JS pueden combinar fácilmente diferentes estilos, como el funcional y el POO, dentro de sí mismos. En los lugares donde esto está justificado, implementaremos código utilizando diferentes estilos. Entonces será más fácil separar la esencia del problema de la forma de resolverlo. Aprenderás a elegir la solución adecuada según la situación, y no basándote en la sintaxis memorizada.

Aprendizaje

Al estudiar POO, es importante tener en mente una idea clave. Ningún curso puede desglosar POO de principio a fin en tu mente. Se necesitan años de experiencia, exploración de arquitecturas buenas y malas, reescritura de código y, lo más importante, análisis constante de lo hecho, solo así se producirá una mejora.

La buena noticia es que no se espera esto de un principiante. Es suficiente conocer conceptos generales, algunas características de JS y la sintaxis de todas las construcciones necesarias. El resto se resolverá a medida que se acumule experiencia. Lo que Códica proporciona en los cursos es mucho más de lo necesario para el empleo.

Es importante mencionar a JS aparte. La cantidad de peculiaridades en el comportamiento de diferentes elementos relacionados con POO es simplemente enorme. Hay suficiente material para varios libros y, sorpresa, estos libros están escritos. Son gratuitos y están disponibles en ruso en GitHub. En los lugares apropiados, podrás encontrar enlaces a los capítulos de estos libros en los materiales adicionales. Los cursos mismos se centran en las grandes ideas, sin adentrarse en los detalles técnicos. De lo contrario, es fácil perder el hilo de la narrativa.