Objetos del deseo

Por qué es más importante el qué que el cómo

Para empezar este artículo he de admitir que tarde más de un año en entender la informática (en mi caso la programación) orientada a objetos sobre todo por dos razones; la primera es la baja calidad de los libros informáticos técnicos en España y la segunda era el hecho de que llevaba programando orientado a objetos muchos más años de los que pensaba.

Después de mucho tiempo de vagar por libros de C++ que no explicaban realmente que es la O.O. (orientación a objetos) y cuando ya había hecho algunos programas pude, por fin, entender la esencia de la misma gracias a un librillo que llevaba ágilmente al programador de C++ hacia el, ahora ya probablemente difunto, mundo de Java. La esencia, que pese a ser simple se comenta en pocos libros, es que la O.O. es el método de trabajo que se centra en la definición de los datos y en su flujo de evolución a lo largo del ciclo de vida del software, en vez de centrarse en los algoritmos que los usan; comparada con esta simple afirmación toda la verborrea de herencia, polimorfismo y operadores sobrecargados se convierte en un mero azúcar sintáctico. Y los nuevos objetos y métodos son la enésima encarnación de las estructuras de datos y el código del viejo adagio del profesor Wirth.

Estos conceptos que llevan ya tiempo aplicándose en la programación, con más o menos acierto y éxito, hicieron su aparición en el mundo de la informática personal (en una medida masiva) de la mano de la mayor novedad de Windows 95, era esta el escritorio orientado a objetos. Este fue el mayor y, en mi opinión, único acierto de la empresa de Redmond en su gran apuesta (y triunfo) en el campo de la microinformática. Pero ellos mismos se dieron cuenta del peligro que eso generaba y rectificaron a tiempo antes de que la gente se diese cuenta de las ventajas de la O.O. para volver al viejo paradigma.

Pero antes de entrar en profundidad merece la pena reseñar que un concepto muy semejante ya existía en un mundo en ese momento mucho más maduro; en UNIX todo estaba orientado a ficheros que ejercían la función de objetos universales, de ese modo, tanto los altavoces, como las pantallas y la conexiones de red se podían tratar como ficheros lo cual agregaba una generalidad absoluta a cualquier utilidad desarrollada para el manejo de ficheros. No es de extrañar que vuelva a ser en este campo donde se estén llevando a cabo los avances más importantes gracias a los nuevos escritorios de UNIX (aunque sobre todo en Linux), orientados a objetos y a servicios sobre los mismos distribuidos en red mediante el protocolo Corba sentando las bases de lo que ya es presente, salvo para el yugo de Microsoft, la informática distribuida orientada a objetos.

Y volviendo al tema, yo mismo me asombré del peligro que estaba implícito en el escritorio orientado a objetos de Windows 95: si se usaba con toda su potencia se corría el peligro de que el usuario se diese cuenta de que lo importante son sus datos (los verdaderos objetos) y no los programas que se usen para crearlos y modificarlos (que no son más que métodos, y por lo tanto contingentes) y termine preguntándose ¿Por qué no puedo editar mis textos con cualquier editor, tal como hago con mis ficheros de sonido e imágenes? Para solventar este problema, realmente grave, mi perversa mente ha visto dos acciones claramente evidentes. Por un lado y con Office 95 se inauguró una infame herramienta, la barra de Office que nos recuerda en todo momento que no estamos creando un documento de texto, sino que estamos usando MS Word. Y con Office 97 se culminó el crimen con el fabuloso cambio de todos los formatos de los ficheros, afirmándose el hecho de que no se crean ficheros de texto, sino que son ficheros de Word95 o Word97; además de obligar a una actualización forzada por la posición dominante y la inexistencia de conversores eficientes y/o evidentes.

Este ejemplo nos muestra todos los inconvenientes de usar formatos propietarios con software propietario. Si estos formatos canibalizados por empresas privadas fuesen rediseñados con libertad y pensando en el usuario y no en la cuota de mercado llegaríamos a unos formatos estables y eficaces que nos darían varias libertades.

Por un lado nos daría una libertad de elección en el método (programa) que vamos a utilizar con nuestros datos, y esto devendría en una mayor competencia en el mercado del software y con ello una mayor calidad, esto ya lo podemos ver en los editores de imágenes cuya gran calidad actual se ha logrado gracias a formatos estándares y una alta competencia. Otro ejemplo sangrante son los navegadores de Internet.

Esto también influiría en la liberta de movimiento de los datos, en el espacio y en el tiempo. No nos volveríamos a encontrar con problemas del tipo "vaya, no tienes instalado este programa" y, "vaya, este nuevo programa no lee mis ficheros viejos, a la basura (los datos, no el programa, que sería lo lógico)", ya que daría una mayor estabilidad a nuestras propias creaciones.

Todos estos son puntos fuertes en el software libre que se basa en (o define) estándares abiertos y eficientes, tanto en objetos como en protocolos (que no son más que objetos de comunicación). Esto ya ha sido visto por la propia Microsoft que, aparte de pelearse con los inmanejables 35 millones de líneas de código de Windows 2000, se ha distinguido por boicotear cualquier estándar que enturbie su dominio, como el HTML, y por intentar convencernos de que un método para ver archivos y carpetas es, ni más ni menos, parte integrante del Sistema Operativo.

Cosas veredes, amigo Sancho.