Programación con objetos: el futuro

Aunque la Programación Orientada a Objetos ofrece importantes promesas de futuro, aún existen problemas respecto a las herramientas y la formación del personal. El mejor consejo: comenzar poco a poco con un proyecto piloto y analizar los resultados antes de realizar inversiones importantes.

Parece que todo el mundo estuviera abandonando el Cobol. En un momento u otro, la mayor parte de las publicaciones informáticas ha exaltado las ventajas de la programación orientada a objetos (OOP). Y no es de extrañar. Las promesas que ofrece la programación orientada a objetos son múltiples: componentes reutilizables, rápidos tiempos de entrega, altos porcentajes de éxito para nuevas aplicaciones y programas flexibles. Sin embargo, aunque las historias sobre los éxitos de la OOP -y existen multitud de ellas- son el tema principal de conversación en el sector, los directores de sistemas de información no están preparados para recibir un nuevo remedio mágico para sus problemas de desarrollo de software.

Más exploración que producción

En un estudio reciente realizado por Index Summit, un servicio de investigación y asesoría de la firma CSC Index, un 42% de los usuarios norteamericanos están realizando investigación OOP, comparado con sólo un 6% que se encontraban en fase de desarrollo de producción. De los que están avanzando en el área OOP, la mayoría son desarrolladores y consultores de software independientes.

De todas formas, los beneficios de la reutilización y la promesa de una mayor productividad de los programadores son demasiado importantes para que los desarrolladores de aplicaciones en las empresas los pasen por alto. En una reciente encuesta de ComputerWorld entre 161 usuarios OOP, un 64% aseguraron que la productividad de los programadores aumentó hasta un 50% mediante el uso de métodos OOP.

Las compañías que deseen estar en vanguardia no deben ignorar la programación OOP, pero es importante establecer un equilibrio entre las promesas y la realidad. La consultora Forrester Research asegura que existen multitud de obstáculos a la hora de optar por la programación orientada a objetos. El más importante de éstos no es la tecnología, sino el salto cultural desde la programación tradicional basada en procedimientos a la programación OOP, y la consiguiente necesidad de reciclaje de personal y de inversiones que requiere.

Variedad de productos

Las herramientas propiamente dichas están llegando ya en buena cantidad al mercado. Estos entornos incluyen editores para revisar codificación, depuradores para el seguimiento y corrección de errores, y browsers para analizar la estructura de la codificación y las relaciones mutuas entre los objetos. También incluyen bibliotecas de clase básicas, que contienen objetos de bajo nivel.

No obstante, en general, las herramientas OOP están lejos de haber alcanzado la madurez. Por lo pronto, sólo con gran cuidado y esfuerzo es posible mezclar y combinar bibliotecas de clase, browsers y depuradores de errores. Y lo que es más, existe una gran carencia de una categoría de productos clave; bibliotecas de clases dispuestas para utilizar y orientadas a las aplicaciones comerciales.

Necesidad de más bibliotecas de clases

Las bibliotecas de clases eliminan gran parte del trabajo preliminar necesario para la creación de un objeto. Esencialmente, son conjuntos de categorías predefinidas que los desarrolladores pueden comenzar inmediatamente a poblar de objetos. Al ir apareciendo más bibliotecas de clases disponibles, los desarrolladores en las empresas pueden emplear más tiempo en formar aplicaciones a partir de clases previamente creadas, y menos tiempo en escribir, probar y depurar de errores nuevas clases de objetos. Están disponibles actualmente bibliotecas de clases que ofrecen componentes de bajo nivel. Estos productos, que se conocen a veces como clases de interface, ofrecen componentes de programa básicos tales como botones de interface gráfico de usuario (GUI), o los rectángulos y círculos que se utilizan para crear componentes GUI. También existe una cantidad de bibliotecas de clases de control que realizan funciones middleware tales como la generación de una consulta SQL. Aunque estas clases son útiles, no liberan al desarrollador de tener que diseñar y crear la funcionalidad comercial casi a partir de cero. Esto no será posible hasta que los desarrolladores tengan acceso a bibliotecas de clases de alto nivel (dominios), consistentes en objetos del área comercial, como un bono o una acción. Entonces, el desarrollador podrá formar la aplicación conectando clases predefinidas y llenándolas de objetos.

Browsers y repositorios

Incluso con bibliotecas de clases, no es posible aprovechar las ventajas de la codificación reutilizable si no es posible localizar clases útiles cuando se necesitan. Es aquí donde resultan útiles los browsers y las herramientas de repositorio.

No obstante, incluso aquí, las herramientas requieren mayor madurez. Las pocas herramientas de repositorio que están disponibles ofrecen sólo un soporte de plataforma limitado y unas funciones y características rudimentarias.

Los browsers, que generalmente están integrados con el entorno OOP, muestran las clases existentes en una determinada aplicación. Por ejemplo, muestran gráficamente como ciertos objetos se relacionan con otros objetos, e indican la relación hereditaria correspondiente. En otros casos, sólo es posible listar las clases utilizadas en la aplicación.

Las herramientas de repositorio mantienen las clases en una localización central, haciendo más fácil que múltiples equipos de desarrollo las compartan. También almacenan información semántica sobre las clases, como por ejemplo, dónde, cuándo y cómo deben ser utilizadas. Aunque no es absolutamente necesario disponer de un repositorio, resulta útil cuando aumenta el número de clases y de desarrolladores. Los repositorios se venden por separado de los entornos OOP.

Difícil integración

Finalmente, los desarrolladores se enfrentan al problema de obtener herramientas de diferentes vendedores y que funcionen juntas con facilidad. Los desarrolladores también informan de problemas para combinar bibliotecas de clases procedentes de fuentes diversas. Se puede hacer, pero sólo con mucho cuidado.

La solución a que se llegará con el tiempo consistirá en un repositorio de información de objetos al que podrá dirigirse cualquier herramienta. Los estándares resolverán parte de la dificultad de combinar herramientas y bibliotecas de clases pero, como es corriente, existe una carencia de estándares.

El Object Management Group (OMG) abrió el camino con su Object Request Broker y su Common Object Request Broker Architecture (CORBA), pero esta última no resuelve la forma en que las herramientas y las bibliotecas hablarán y se comunicarán entre sí. Lo que hacen es definir cómo los objetos interactúan en la red y los mecanismos mediante los cuales los usuarios pueden contactar con objetos en otras partes de la red.

Aunque los desarrolladores están realizando progresos con la programación OOP, el sector informático se ha mostrado lento en el seguimiento. Esto se debe probablemente a que aunque se pueden encontrar herramientas que permiten crear aplicaciones de potencia industrial, distan mucho de ser fáciles de utilizar. Para utilizarlas, las empresas se enfrentan a enormes inversiones en formación de personal y ayuda externa, aparte de las herramientas mismas, sólo para llegar al punto en el que comienzan a ser productivas. Al haber sufrido el fracaso de unas grandes inversiones en herramientas CASE que no han dado resultado, los usuarios están comprobando la conveniencia de actuar con mayor precaución esta vez.

Lo que está de actualidad y lo que no

Es más fácil poner objetos en la