Comenzamos con nuestro Curso de Programación Orientada a Objetos, con esta primera introducción en la que veremos qué es, de donde surge, y cuál es su propósito.
La Programación Orientada a Objetos (POO) es un paradigma de programación que se basa en el concepto de “objetos”, que son entidades que encapsulan datos y comportamientos, y las relaciones entre ellos.
La Programación Orientada a Objetos busca:
- Modularidad: Permite dividir un sistema en componentes independientes que pueden ser desarrollados, probados y mantenidos por separado.
- Reutilización: Facilita la reutilización del código a través de la herencia y la composición de clases.
- Flexibilidad: Permite adaptar el software a cambios en los requisitos o en el entorno de ejecución de manera más sencilla.
- Escalabilidad: Permite escalar el software agregando nuevos objetos y clases según sea necesario, sin afectar la estructura existente.
Sin demasiado miedo, podemos decir que es el paradigma de programación que más influencia ha tenido los últimos 50 años.
Pero antes de ponernos a hablar de clases, herencia e interface como locos, vamos a empezar viendo de donde surge, y porqué es tan importante.
Se presupone conocimientos básicos de programación. Si no es el caso, te recomiendo que le eches un ojo a nuestro Curso introducción a la programación
De donde sale la programación orientada a objetos
Nos volvemos 50 años atrás. En esta época la informática estaba en pañales 🐣, y ni las herramientas ni las necesidades en cuanto a programas eran los que son hoy en día.
Por así decirlo, “estaba todo por hacer”. Pero, lo ya tenían claro en esa época es que era conveniente agrupar datos en contenedores (estructuras de datos).
Por ejemplo, si tenías una persona, era lógico tener
Persona {
string Nombre;
string Apellidos;
DateTime FechaNacimiento;
}
Esta agrupación era conveniente, de forma que podríamos trabajar con una Persona
de forma conjunta. De lo contrario, corrías el riesgo de mezclar sin querer los datos de una persona con otra.
Además, estas agrupaciones se podían componer. Es decir, una de tus agrupaciones podía tener dentro dentro otras agrupaciones. Por ejemplo, imaginemos que querías hacer un programa que dibujara formas geométricas.
Point2D {
int x;
int y;
}
Shape {
Point2D Position; // composición con Point2D
int Rotation;
int Width;
int Height;
}
Donde Shape
usa Point2D
como posición. Hasta aquí todo bien. Tenemos nuestros contenedores de datos (muy bonitos y muy prácticos).
Ahora podrías usar tu figura, y usarla para crear Cuadrados, Rectángulos, Triángulos equiláteros y Círculos. Simplemente usabas tu contenedor Shape
, y rellenabas los datos según necesitaras.
Se viene el problema
El problema surge cuando, además de datos, se le quiere añadir comportamiento.
Imagina que queremos añadir una función que calcule el área. Tiene sentido que una figura sepa calcular su área, porque es algo propio e interno de la figura (no depende de nadie más).
En esos momentos, la tendencia natural para resolver esto era emplear Referencias a funciones como miembros de tu agrupación. Por ejemplo,
Shape {
Point2D Position;
int Rotation;
int Width;
int Height;
int GetArea(); // hemos añadido una referencia a una función
}
Pero claro, un Rectángulo, un Círculo, y un Triángulo equilátero, no calculan su Area con la misma función.
Pues no pasa nada, voy creando figuras. Tal cual las creo, les voy cambiando la función (¡directamente en memoria!) por la función según lo que necesite.
Y ya la has cagado…
3000 líneas, y 217 ficheros más abajo, cuando llamabas a una función no tenías ni idea de que función estabas llamando, porque te la habían cambiado 14 veces a lo largo del programa.
¡Imagina el problema de tener que hacer una plataforma de pagos y no tener 100% claro cómo funciona cada parte! (seguramente, te acabaran despidiendo o demandando o ambas)
La programación orientada a objetos
Haciéndolo de esta forma, la situación se había liado pero bien. No había Dios que hiciera programas bien así, no era sostenible. Así que unas personas muy inteligentes, se pusieron a pensar.
Se pusieron a pensar mucho. A visualizar universos de 12 dimensiones. A modelar el mundo. A sentar las bases de un nuevo paradigma de la programación.
No solo intentaban resolver un problema. Intentaban inventar una metodología que permitiera abordar de forma sistemática la resolución de cualquier problema de programación (que no es moco de pavo).
Después de mucho pensar dijeron, ¡ya lo tenemos 💡! Lo que necesitamos son cuatro pilares:
- Abstracción, a través de objetos
- Encapsulación
- Herencia
- Polimorfismo
Y se quedaron tan panchos. Veremos estos cuatro pilares en su momento, qué es lo que son, y que función cubría cada uno de ellos.
Pero lo importante hoy es remarcar que no son “leyes mágicas” ni verdades absolutas. Es lo que necesitaban ellos, para arreglar el tinglado que tenían montado.
La programación orientada a objetos en la actualidad
Ha pasado mucho tiempo desde que las bases se establecieron la programación orientada a objetos. En este tiempo, han cambiado muchas cosas.
Actualmente, incluso aumenta la cantidad de detractores de la programación orientada a objetos. Planteándose si es un paradigma que sigue siendo relevante en la actualidad, o ha quedado anticuado. Bueno, aquí pasan varias cosas.
Por un lado, las necesidades actuales no son las mismas que cuando esas personas muy inteligentes se sentaron a pensar. La programación ahora es mucho más compleja, y abarca necesidades que en esos momento ni se vislumbraban.
Por otro lado, la programación a objetos también ha cambiado. De hecho se ha vuelto más compleja y más rígida. Incluso, en frase de alguno de sus creadores, ha evolucionado y desviado del propósito original.
Eso no significa que la programación orientada a objetos sea mala o esté anticuada. Al contrario, hemos dicho que es un paradigma que sale de forma natural, a medida que vas haciendo programas cada vez más complejos.
Lo que sí es necesario es entender las bases y el propósito de cada una de ellas. No es un problema del paradigma, si no de su uso. Hay que saber aplicarlo, y adaptarlo a los tiempos modernos.
A eso nos dedicaremos en este curso, donde veremos todas estas cosas. De donde viene cada una de ellas. Y las prácticas que tienen sentido aplicar hoy, y las que conviene evitar.