Java no está orientado a componentes

Habría que empezar distinguiendo entre "Java lenguaje" y "Java plataforma". Esto que voy a plantear ahora es una de las críticas a Java como lenguaje: Java no es un lenguaje "orientado a componentes".

¿En qué consiste tal presunta carencia? Sostengo la teoría fácilmente verificable sobre el avance por olas de la Programación Orientada a Objetos. Obviemos las olas "prehistóricas", es decir, aquellas anteriores al éxito comercial de C++. Tendríamos entonces:

• En la primera ola, el modelo de lenguaje sería C++ (para bien y para mal): strong typing, herencia múltiple, soporte opcional para golosinas sintácticas como sobrecarga de operadores o sobrecarga de métodos... En mi opinión, Eiffel, a pesar de ser concebido como un antídoto al hartazgo de C++, pertenecería a esa primera ola. Esta es una simplificación exagerada, por supuesto, pero va a sernos útil. De entrada, porque en muchos sitios sigue idolatrándose a C++ como el culmen de la P.O.O.


• No hay mucho acuerdo sobre esto, pero en mi opinión, el siguiente paso revolucionario lo da Alan Cooper con Visual Basic. No fue un invento con glamour, pero aportó la idea de componente. El fallo de Cooper fue no pensar que las ideas que aportó sobre interfaz visual podían afectar al lenguaje subyacente. Quien dio ese paso fue Anders Hejlsberg con Delphi, y ya conocemos la consecuencia: la supremacía absoluta de un lenguaje comercial durante una buena temporada.

¿En qué consiste la idea del componente? La industria del software saliva como el perro de Pavlov cada vez que alguien menciona la metáfora electrónica, de modo que vamos a utilizarla una vez más. Si la aparición de las clases y objetos de la primera ola se puede parangonar con el invento del transistor, la entrada en escena de los componentes es el equivalente en software de la aparición de las primeras placas o circuitos impresos. Cuando era niño, tuve una larga temporada en la que me aficioné a la electrónica. ¿Ha probado alguna vez a implementar un circuito determinado (un amplificador, un pedal para guitarra) con transistores y otros componentes electrónicos habituales... pero sin usar una placa apropiada? Es la placa lo que hace posible, por una parte, una implementación rápida y limpia, sin interferencias, del circuito. Por otra parte, la placa permite acelerar la fabricación de estos circuitos. Sin el circuito impreso, no tendríamos los microprocesadores actuales.

Traduzcamos la idea al mundo del software. La idea del componente consiste en formalizar las técnicas que utilizan las instancias de clases para interactuar entre ellas. El problema es que estas interacciones, sorprendentemente, no se pueden simular directamente con los recursos de la P.O.O. de la primera ola. Por una parte, tenemos el concepto de evento. Java no tiene eventos, hablando con propiedad, y obliga a implementar este tipo de interacción a través de tipos de interfaz y clases anónimas. El concepto de evento no sólo es útil para los componentes al estilo VCL o Windows Forms, sino que incluso ha demostrado ser útil, en una de sus muchas variantes posibles, en COM+.

¿Y las propiedades, qué pintan en todo esto? La raison d'être de éstas es la serialización, que es, a su vez, lo que hace posible la configuración inicial de un componente con la ayuda de un Inspector de Objetos. ¡Java tampoco tiene propiedades! Nos obliga a trabajar con pares de métodos: GetText/SetText para lo que podría ser simplemente una propiedad Text.

¿Por qué Java omite estos recursos tan probadamente útiles? Es probable que la culpa la tenga el rígido control que ejerce Sun sobre su lenguaje. De no ser por este exceso de celo, estas carencias se podrían resolver rápidamente. De todos modos, no son los únicos problemas de Java como lenguaje. Tampoco la evolución de la P.O.O. se detuvo en la segunda ola. Más adelante escribiré sobre la tercera ola, en la que, curiosamente, Java sí tuvo una influencia decisiva.