Qué es la Programación Orientada a Objetos

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.

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, o estructuras. 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 el Nombre de una persona, con la FechaNacimiento de 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..

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 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, como es una referencia, voy cambiando 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 un pago, y no tener 100% claro que narices está haciendo la función! Pues, seguramente, te acabaran despidiendo o demandando.

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.

Es decir, 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

Veremos estos cuatro pilares en su momento, qué es lo que son, y que función cubrían. 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.