La Programación orientada a objetos y The Beatles.

La programación orientada a objetos o POO, es una de esas cosas famosas de las que todos los programadores hablan, como si se tratara de una banda de rock famosa.

Por otro lado, la POO, es un concepto difícil, es como la energía oscura de los paradigmas. Algo que los físicos saben que existe, llama la atención, y hasta la pueden calcular, pero que nadie sabe explicar hasta ahora.

Un poco de historia

La historia de la POO como paradigma, se parece mucho a la historia de The Beatles, cuya primer intento de pegar en una discográfica, en 1961, fue un completo desastre. Los rechazaron diciendo que no tenían futuro (Me recuerda a una presentación de proyecto en la universidad). Pero luego ya todos sabemos cómo terminó la historia.

La POO también fue rechazada cuando vio la luz por primera vez, allá a inicios de los 60 en los laboratorios del MIT y XEROX. Se manejó solo en ámbitos académicos, entre oscuros documentos técnicos e implementaciones limitadas, como el mismo hardware de la época.

En ese entonces, nadie daba ni dos pepinos por la POO. Se puede justificar de muchas maneras el porqué de este rechazo inicial, pero lo importante es que en los 80, resurgió para convertirse en el Santo Grial de los programadores, o La Piedra filosofal que salvaría al mundo de la programación del colapso, y ayudaría a solucionar todos los problemas que habían atormentado al desarrollo de software.

Alguien despistado o poco conocedor, podría pensar que la POO vino para salvarnos y que el mundo antes de él era una anarquía, llena de salvajes programadores, jalándose los pelos por no poder solucionar sus problemas.

Nada de eso es verdad. El mundo del desarrollo de software giraba ya antes de la POO y hubiera seguido girando, con sus días y sus noches, si esta nunca hubiera aparecido.

Hay una verdad incómoda que muchos defensores de la POO, se niegan a aceptar: «Todo lo que se pueda hace con POO, se puede hacer sin POO».

Si esto pareciera una verdad a medias, veamos, por ejemplo, los programas hechos en C (un lenguaje sin POO): El kernel de Linux, UNIX, Mac OS X, están escritos en C, incluyendo las versiones tempranas de Windows.

Aplicaciones famosas como PosgreSQL, GIMP, Servidor Web Apache, Emacs, VIM, o Geany, además de muchos compiladores o intérpretes.

Aún las aplicaciones más complejas, pueden crearse completamente bien sin el paradigma POO. Incluso los primeros compiladores/intérpretes de lenguajes POO fueron creados con lenguajes sin POO, como es lógico.

¿Por qué se hizo tan famosa la POO?

Se hizo famosa, entre otras razones, porque ofrecía un conjunto de características nuevas (algunas no tanto), más allá de la simple filosofía de la POO, que aliviaban algunos aspectos (y complicaban otros) de la pesada tarea del desarrollo de software.

Al igual que The Beatles, que además de ser una banda y de rock, nos ofrecieron tres músicos talentosos (Cuatro si consideramos a Ringo Starr), la Programación Orientada a Objetos, vino con algo más que Clases y Objetos:

• Herencia.
• Polimorfismo.
• Encapsulamiento.

Tal vez algunos consideren, adicionalmente la Abstracción o alguna otra característica, pero es un tema de gustos, ya que ni los mismos expertos se ponen de acuerdo y hay posiciones encontradas.

Inclusive algunas implementaciones de orientación a objetos, como la original de Javascript, no incluye clases, mientras que la gran mayoría de lenguajes OO, como C++, se basan en clases.

Entre las otras razones, que hicieron que la POO fuera bien recibida estaban:

• Permitía modelar bien el mundo concreto.
• Fue patrocinada por empresas influyentes.
• Se adaptaba bien a los entornos gráficos muy de moda a fines de los 80.
• La tecnología estaba lo suficiente madura para producir intérpretes y compiladores POO.

El hecho de la POO facilite el modelamiento es importante, porque el éxito de una técnica en ingeniería es el modelado (Ver el artículo https://blogdetito.com/2020/12/22/el-modelado-la-clave-de-la-ingenieria/).

La facilidad que proporciona el paradigma POO para el modelamiento, es sorprendente y puede haber sido determinante en su éxito. Cuando uno empieza a pensar en objetos, los problemas se modelan casi automáticamente. Y no solo para objetos concretos, sino que muchas entidades abstractas, como un error, o un número, se modelan también de forma simple.

Como se vende

En mis clases de programación, solía usar fórmulas nemotécnicas para enseñar a mis alumnos, los conceptos claves de la POO (con los cuales yo no estaba necesariamente de acuerdo). Para la POO solía usar la palabra «Pecho», que engloba los principales «pilares» de la POO:

Cuando se vende la Programación Orientada a Objetos, además de las Clases y Objetos, el cliente, da por hecho que el paquete viene con adicionales (que nadie pidió), como el encapsulamiento, la abstracción, la herencia y polimorfismo. Y como si eso fuera poco, a veces se incluye recolección de basura, herencia múltiple, interfaces, mensajes, la sobrecarga de operadores, y aún más.

Es decir, comprar POO es una ganga. Por eso nadie se resiste a usarla. Si yo le intentara vender un lenguaje orientado a objetos que no incluyera herencia (que los hay), probablemente me lo rechazarían sin permitirme dar explicaciones.

Así que cuando se dice que alguien está usando POO, se da por sentado que está manejando alguna característica adicional, como herencia o polimorfismo.

¿Pero serán necesarias esas características adicionales como parte del concepto de la POO?

¿Qué es realmente?

Llegados a este punto, cabe preguntarnos ¿Qué es la POO? Y sí, ya sabemos que es un paradigma, pero ¿En qué consiste ese paradigma?

La respuesta es tan sencilla que puede decepcionar a muchos «especialistas», porque hasta un niño pudo haberla dado:

La Programación Orientada a Objetos, consiste en programar usando objetos.

Autor: Mi niño interior.

¿Así nada más? ¿Y la herencia, el polimorfismo, los métodos virtuales, la recolección de Java basura?

Pues nada de eso es necesario. Estas son características adicionales que se venden con el concepto POO, pero que no definen o condicionan a la POO.

Si aún hay dudas, veamos la definición de Wikipedia:

«Object-oriented programming (OOP) is a programming paradigm based on the concept of «objects«»

Eso es todo. That’s all. La POO es un paradigma basado en «objetos».

Todo los demás son definiciones adicionales. El concepto clave aquí es «objeto», que finalmente es solo una estructura de datos que engloba atributos y métodos.

Hay lenguajes de programación que nos permiten programar en el estilo POO y que no incluyen el concepto de clases (como Javascript), ni de herencia (como Go), ni recolección de basura (como C++). Es más, se puede programar al estilo POO, en lenguajes No-POO, porque finalmente la POO es un paradigma, una forma de hacer las cosas. Las implementaciones que hagan los lenguajes son solo interpretaciones del paradigma.

La POO seguirá siendo POO aún sin polimorfismo o herencia, así como «Los Beatles» seguirían siendo «Los Beatles» sin «Hey Jude» o «Yesterday».

Así que cuando alguien les venga a decir que POO es herencia, polimorfismo o encapsulamiento, mándelo a freír monos.

Y hablando de monos, en el siguiente artículo de esta serie, hablaremos de las bananas y los programadores.