Razones para el surgimiento de OOP

"¡Hola, amigo! Quiero que entiendas el propósito de la programación orientada a objetos. Así que te voy a contar una historia".

Había una vez una pequeña empresa que enviaba mercancías al espacio exterior...

"¿Como Galactic Rush?"

"Sí, como Galactic Rush. 5 personas trabajaban allí. El primero manejaba las finanzas, el segundo trabajaba en el almacén, el tercero hacía el envío, el cuarto estaba a cargo de la publicidad y el quinto supervisaba todo".

Trabajaron duro y florecieron. La empresa tenía una buena reputación y ganaba mucho dinero. Cada año aumentaba el número de pedidos, por lo que el director ejecutivo tuvo que contratar más empleados. Varios para el almacén, varios para hacer el envío, otro cajero y un comercializador para aumentar las ventas.

Fue entonces cuando comenzaron los problemas. Había más personal y comenzaron a interferir entre sí .

El comercializador gastó todo el dinero en una nueva campaña publicitaria, sin dejar efectivo disponible para comprar los productos que se suponía que debían enviarse con urgencia.

El almacén tenía 10 cajas con hiperimpulsores nuevos para enviar una vez al mes. Un mensajero se fue volando con un hiperimpulsor, lo que provocó que el pedido de otro cliente de 10 hiperimpulsores se retrasara otro mes. El primer mensajero simplemente no sabía que el segundo mensajero estaba cumpliendo con el otro pedido.

El nuevo director ejecutivo adjunto envió un mensajero en un barco para comprar bienes, y todo lo demás esperó al próximo barco disponible. Había muchos envíos urgentes, pero este asistente solo gestionaba compras y estaba tratando de hacer bien su trabajo. Cuanto mejor una persona realizaba sus deberes, más interfería con el resto .

Al analizar la situación, el director ejecutivo se dio cuenta de que recursos importantes como el barco, el dinero en efectivo y los bienes no se gastaban de manera óptima, sino más bien según el criterio de "primero en llegar, primero en ser servido". Cualquiera podría tomar recursos para realizar su trabajo, amenazando la productividad del resto de los empleados y de la empresa.

Algo había que hacer. El CEO decidió dividir la empresa monolítica en varios departamentos. Creó un departamento de envíos, un departamento de marketing, un departamento de compras, un departamento de finanzas y un departamento de almacenamiento. Ahora nadie podía simplemente tomar el barco. El jefe del departamento de envíos recibió toda la información de envío y entregó el barco al mensajero cuya entrega sería más rentable para la empresa. Además, el almacén no permitía que los mensajeros simplemente tomaran las mercancías. Ellos controlaron el proceso. El departamento de finanzas no podría asignar dinero para marketing si supiera que pronto habría una compra. Cada departamento tenía una figura pública: el jefe de departamento. La estructura interna de cada departamento era asunto propio.Si un mensajero quisiera llevarse algunos bienes, iría al gerente del almacén, no al almacén. Cuando llegaba un nuevo pedido, iba al jefe del departamento de envíos ( persona pública ), no al mensajero ( persona privada ).

En otras palabras, el CEO agrupó los recursos y acciones en departamentos y prohibió que otros interfirieran con las estructuras departamentales internas. Solo se pudo contactar a personas específicas.

En términos de programación orientada a objetos, esto no es más que dividir un programa en objetos. Un programa monolítico, que consta de funciones y variables, se convierte en un programa que consta de objetos. Y estos objetos contienen variables y funciones.

"Espera un minuto. ¿Estás diciendo que el problema era que cada empleado tenía acceso ilimitado a los recursos y podía dar órdenes a cualquier otro empleado?"

"Sí exactamente."

"Interesante. Introdujimos una pequeña restricción, pero recibimos más pedidos. Y pudieron mantener un mejor control de todo".

"Sí. Divide y vencerás en estado puro".

"Tal como dijiste, divide y vencerás. Eso es algo para recordar".