La programación orientada a objetos a debate

La programación orientada a objetos, OOP (Object Oriented Programming) está considerada por algunos como la respuesta a los problemas de desarrollo de software. La OOP promete ayudar a las compañías a ahorrar tiempo, recursos y dinero, permitiendo crear rápidamente aplicaciones de empresa dispuestas para funcionar, en base a objetos autónomos predefinidos. Sin embargo, los escépticos señalan que se requiere para ello un difícil y lento periodo de aprendizaje, junto a expectativas frustradas y problemas de compatibilidad. ¿Quién tiene la razón?

A favor

Si usted ha utilizado alguna vez de niño juguetes de construcción de Lego, comprenderá en qué consiste la orientación a objetos. Utilizando estas piezas de juguete, se puede crear una cabaña, desmontarla y reutilizar los componentes para construir un fuerte. Las piezas prefabricadas fueron la base de la Era Industrial, mientras que los objetos, componentes y circuitos integrados por software son la base de la Era de la Información. Sin ellos, el desarrollo de software no puede progresar como una entidad activa y saludable. Es sorprendente que estos conceptos sencillos resulten difíciles de comprender, ya que son intuitivamente obvios.

La programación orientada a objetos no sólo puede utilizarse para crear nuevas aplicaciones a nivel de empresa, sino que también permite distribuir y compartir objetos a todos los niveles de la empresa mediante agentes inteligentes.

Los objetos tienen muchas ramificaciones para sistemas de información en la totalidad de una organización. Algunas facetas de la OOP requieren un cambio fundamental en la forma en que las grandes compañías abordan la cuestión del software. Es importante comprender estos aspectos de la OOP, y cómo requieren tanto un cambio cultural como un cambio de paradigma difícil pero alcanzable en toda la empresa.

La encapsulación es un aspecto clave de OOP que convierte toda la información relativa a un objeto específico del mundo real, como por ejemplo un cliente, a un único objeto maestro o patrón original digital. Este objeto original reside en un almacén de objetos virtual al que pueden acceder las aplicaciones en toda la organización, y este tipo de encapsulación representa un enorme ahorro de costos y un aumento de la eficiencia sólo en costos de mantenimiento, sin mencionar la mayor precisión y el mejor servicio al cliente.

En contraste, un sistema antiguo probablemente contendrá alguna información sobre un cliente en una base de datos y otra información sobre ese mismo cliente en otra base de datos diferente. Además, por lo general, una misma información sobre un cliente reside en múltiples bases de datos, cada una de las cuales puede contener errores y, para empeorar las cosas, las bases de datos son a veces propietarias o de creación propia, resultan difíciles de integrar y requieren muchas personas para su mantenimiento.

La encapsulación impide también la existencia de codificación frágil gracias a la disminución del número de presunciones o supuestos, permitiendo así rápidos cambios a las aplicaciones. Una de las ventajas de la programación OOP que se observan con más frecuencia es la reutilización del software. Este es un beneficio de enormes proporciones, ya que reduce el tiempo de desarrollo y por lo tanto los costos. Donde los directores de desarrollo de software se equivocan a veces es en intentar vender la reutilización como si fuera un remedio mágico. Estos directores suelen mostrarse con frecuencia reacios a incluir en sus planes el tiempo adicional necesario para crear codificación reutilizable.

Los verdaderos lenguajes orientados a objetos, como Smalltalk y Java, soportan la reutilización mediante la capacidad de herencia. Así, si se ha escrito ya por ejemplo la codificación para una clase general de objetos llamada "pelota", no hay que reescribir esa codificación para subclases como "pelota de fútbol" o "pelota de golf", sino que es suficiente con escribir la codificación que es diferente para cada subclase, como por ejemplo, "con costuras", o "con rebordes". Debido a esta capacidad de herencia, la reutilización aparece como un subproducto durante el desarrollo normal en la programación OOP.

Cuando el departamento informático de una empresa recibe el encargo de crear un nuevo sistema, generalmente tiene lugar un fuerte rechazo a descifrar la críptica y extraña codificación realizada por otra persona. En lugar de ello, los programadores escriben nueva codificación o acumulan otra nueva capa sobre el material antiguo, complicando así aún más el problema. Esto contrasta con la actividad de los programadores en la programación orientada a objetos. Los verdaderamente buenos son en parte plagiarios, en parte artistas y en parte integradores de sistemas. Toman objetos de cualquier parte, los reutilizan, los modifican en caso necesario, y los integran a velocidades de vértigo. Sin embargo, para aprovechar al máximo su trabajo, una empresa necesita disponer de un jefe que coordine sus actividades. Entonces, ¿por qué la programación orientada a objetos no ha alcanzado una aceptación más amplia? Uno de los motivos está en que representa una seria amenaza a las organizaciones y departamentos informáticos tradicionales. Los principales detractores de la programación orientada a objetos son generalmente aquellos que pueden perder más: los creadores de imperios centrados en el control, que son juzgados por el tamaño de su personal, y no por los ahorros que obtienen para su compañía.

Otra razón está en la dificultad o falta de dedicación que encuentran algunas organizaciones al intentar conseguir que el paradigma cambie a la utilización de objetos. Es precisamente este cambio de modelo o paradigma lo que aducen los que se oponen a la programación OOP como motivo para no utilizarla. Es necesario que se comprenda que este cambio fundamental es obligatorio para producir a su vez un cambio significativo, y que ello requiere tiempo. Cuando las promesas de la programación orientada a objetos no se cumplen inmediatamente, los directores culpan a la tecnología, interrumpen todas las nuevas clases, y suspenden la actividad a mitad del cambio de paradigma. Es entonces cuando los antiguos miembros del departamento de Sistemas se alegran, ya que sus puestos de trabajo y sus imperios están seguros nuevamente, y desaparece la incomodidad de tener que aprender algo nuevo.

En un futuro próximo, todo el software será orientado a objetos. La tendencia es obvia en esta dirección, como demuestra el crecimiento de lenguajes orientados a objetos como Smalltalk, C++ y, ahora, Java. El motivo de este movimiento está en que los objetos de software son un reflejo del mundo real. Los registros, campos y estructuras están orientados al ordenador y, una vez que se comprenden e interpretan los objetos en el software lo mismo que se jugaba de niño con objetos, la conveniencia de la programación OOP resulta obvia.

¿Desea usted permanecer en la cola de este cambio de paradigma mientras sus competidores están utilizando objetos para maniobrar de forma consistente dentro de su ciclo de desarrollo? Constantemente oímos la pregunta: "¿Han alcanzado ya los objetos la madurez necesaria para entrar en plena producción?". Desde luego, hace años que la han alcanzado. La cuestión es, ¿cuándo estarán preparados los departamentos informáticos de las empresas para utilizarlos?

En contra

Con la misma inexorabilidad que la muerte y los impuestos, la programación OOP clásica, tal como quedó definida a mitad de los años 80, fracasará como paradigma de programación para crear aplicaciones a nivel de Sistemas de Información de empresa. Las empresas y organizaciones que intenten vivir bajo una programación OOP clásica morirán bajo ella.

¿Cuáles son las características más notables de la programación OOP "clásica"? La implementación OOP tiene lugar en un lengua