Referencia: Este artículo es una tradución al español de Object Oriented Oblivion por Ben Lynn.

Introducción#

Los lenguajes de programación orientados a objetos son un gran error; un tortuoso desvío que los informáticos nunca deberían haber tomado.

La filosofía limitada de un tamaño para todos de algunos lenguajes orientados a objetos hace que la codificación sea engorrosa. Estoy molesto conmigo mismo porque fui un cruzado del imperio orientado a los objetos durante años; pensé que todos los datos podrían ser forzados a una jerarquía elegante si tenía suficiente habilidad, y que todos los que no usaban objetos estaban creando un desorden innecesario. Uno sólo tiene que leer sobre el “problema” del elipse circular para ver a través de este engaño.

Además del sistema de camisa de fuerza, mi otra gran queja es el estatus de segunda clase de las funciones. ¿Los diseñadores de lenguajes no han aprendido nada de la programación funcional? Una buena notación para las funciones y los cierres o cerraduras permiten que el código, por lo demás torpe, se exprese de forma clara y concisa.

Cuando debo usar un lenguaje orientado a objetos, evito la herencia, que incluso se equivoca en la inicialización de objetos y lucho por obtener el equivalente de construcciones C simples como los punteros de funciones. Aunque puedo superar la mayoría de las deficiencias, siento que estoy peleando contra la burocracia y luchando con burocracia. En lugar de hablar a la máquina y compañeros programadores, estoy rellenando los formularios que me da el compilador.

¿Hacker o curandero?#

La programación es difícil. Dijo Brian Kernighan:

Controlar la complejidad es la esencia de la programación informática.

Esto probablemente se sabía incluso antes de que se inventara el ordenador.

Teorizo que los investigadores demasiado entusiastas difundieron el rumor de que el diseño orientado a objetos simplificaría la programación alrededor de la década de 1980. Debe haber sido fácil de creer, porque cualquiera querría una píldora mágica para aliviar sus complejos dolores. Les prometieron que podrían limpiar los sistemas reorganizándolos en jerarquías de clases. Si no es así, entonces usted está viendo el problema de manera incorrecta: trate de mezclarse en las clases. O aplique un patrón de diseño genial con un nombre genial.

Muchos se vieron atrapados en la locura. De repente, printf("0x%08x\n", x) es menos claro que:

1

std::cout << std::hex << std::setfill('0') << std::setw(8) << x << std::dec << std::endl;

(del C++ FQA). La programación funcional es obsoleta. De hecho, las funciones son obsoletas: como mucho, se puede tener una clase con un solo método. La prolijidad es loable. Hermosas gemas como esta línea de Haskell para calcular los números de Fibonacci:

1

fib = (fibs !!) where fibs = 0 : scanl (+) 1 fibs

(de Wikipedia) son demasiado difíciles de entender. En cambio, se les enseña a los estudiantes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

public class Fibonacci {
    public static long fib(int n) {
        if (n <= 1) return n;
        else return fib(n-1) + fib(n-2);
    }

    public static void main(String[] args) {
        int n = Integer.parseInt(args[0]);
        for (int i = 1; i <= n; i++)
            StdOut.println(i + ": " + fib(i));
    }
}

Los nuevos lenguajes de programación deben estar orientados a objetos, o al menos fingir estarlo, para que se les tome en serio. Incluso Guy Steele se unió al lado oscuro.

Algunos vieron a través de la artimaña:

Aunque sus advertencias cayeron en oídos sordos. El artículo de Wikipedia sobre programación orientada a objetos concluye con numerosas citas similares. Vea ¡Programación Orientada a Objetos Sobrevendida! para más información. Mi crítica favorita de este completo sitio es que los proponentes afirman que la OOP se ajusta mejor a la forma en que la gente piensa, mientras que al mismo tiempo afirman que toma años de estudio para desarrollar la competencia. ¿Cómo pueden pasar años de estudio para pensar con naturalidad?

Un regreso a la normalidad#

Al final, la realidad triunfó. Algunos programadores a los que se les enseñaron lenguajes orientados a objetos, sin embargo, pasaron la mayor parte de su tiempo en lenguajes “divertidos” como Perl o Python. Después de todo, ¿quién disfruta de la caldera y la verbosidad de Java?.

A medida que la ideología envejeció, perdió su novedad. Apuesto a que muchos de los que invirtieron mucho en objetos no lograron ver los beneficios prometidos, y ahora son escépticos. Por fin se dan las condiciones para escapar de los Años Oscuros. Tal vez sea un sesgo de confirmación, pero veo señales de que se acerca la Ilustración.

Nuevos lenguajes como Erlang y Go se han hecho populares a pesar de no estar orientados a objetos. Por el contrario, los lenguajes orientados a objetos están adquiriendo características de la programación funcional. Ya a finales de los 90, Java 1.1 soportaba clases en línea anónimas, lo que hace que la programación funcional sea casi soportable. Años más tarde, Scala, con un importante soporte para la programación funcional, se construyó sobre la infraestructura Java. C++11 soporta funciones lambda, y en 2014, incluso Java 8 finalmente añadió lambdas.

El marco de trabajo de Google MapReduce ha sido probado en batalla y ha adquirido fama. Su nombre y diseño se inspiran en las construcciones de programación funcional: Ver “Why Functional Programming Matters”. Esto puede animar a los programadores a aprender sobre ellos.

La marea puede estar cambiando en la academia. Robert Dewar, ex profesor de ciencias de la computación de la Universidad de Nueva York, lamenta la baja calidad de los títulos después de haber empezado a hacer hincapié en Java. Más recientemente, la Universidad Carnegie Mellon eliminó la programación orientada a objetos del plan de estudios introductorio de ciencias de la computación, porque es intrínsecamente antimodular y antiparalela.

Lucha de clases#

Herencia. En una palabra, hemos resumido el problema con la programación orientada a objetos. Este maldito concepto es responsable de todo, desde debates sin sentido sobre es-un versus tiene-un, hasta problemas como la anomalía hereditaria.

La herencia inicialmente parece facilitar ingeniosamente la reutilización del código. Con una sola declaración, evitamos duplicar un montón de definiciones de miembros y métodos. Sin embargo, es como encender un horno para quemar un cabello. En un examen más detallado, la herencia es copiar y pegar: contundente, cruda y raramente deseable. ¿Cómo reutilizamos el código de más de una fuente? ¿Qué pasa si sólo queremos reutilizar ciertos bits? ¿Mis cambios a una clase arruinarán a una subclase?

Arte abstracto#

Mi desventura con la programación orientada a objetos no fue del todo infructuosa. Aprendí sobre las clases de base puramente abstractas. Con el tiempo vi cómo se disolvieron muchos de los problemas que encontré con la herencia.

En las clases puramente abstractas declaramos sólo los métodos públicos, por lo que limitamos el daño que puede causar la herencia, ya que no puede duplicar ningún detalle de la implementación. En este contexto, la herencia se vuelve realmente útil.

Entonces, ¿por qué no hacer de las clases puramente abstractas el único tipo disponible? Java casi lo hace: sus interfaces son clases puramente abstractas. Desafortunadamente, a cada clase se le permite pecar una vez: se recibe una herencia maligna gratis.

Otros lenguajes han tenido éxito, permitiendo una herencia menos por clase que Java. Por ejemplo, las clases puramente abstractas se asemejan a las interfaces Go y a las clases de tipo Haskell, y en estos lenguajes no existe una herencia orientada a objetos.

Ben Lynn - Object-oriented oblivion