Las ideas básicas de la orientación a objetos

Historia

Las ideas básicas de la orientación a objetos nacen a principios de los años 60 en la universidad de Noruega. Un equipo dirigi-do por el Dr. Nygaard se dedicaba a desarrollar sistemas infor-máticos para realizar simulaciones de sistemas físicos como simular el funcionamiento y obtener el rendimiento de un motor. La dificultad en la que se encontraban era doble. Por un lado los programas eran muy complejos y, por otro, forzosamente tenian que ser muy modificados. Este segundo punto era especialmente problemático, ya que la razón de ser de los programas era el cambio y no sólo se requerían varias iteraciones para obtener un producto con el rendimiento deseado, sino que muchas veces se querían obtener diversas alternativas viables cada una con sus ventajas e inconvenientes.

La solución que idearon fue diseñar el programa paralelamente al objeto físico. Es decir, si el objeto físico tenía cien componentes, el programa también tendría cien módulos, uno por cada pieza. Partiendo el programa de esta manera, había una total correspondencia entre el sistema físico y el sistema informático. Así, cada pieza física tenía su abstracción informática en un módulo. De la misma manera que los sistemas físicos se comunican enviándose señales, los módulos informáticos se comunicarían enviándose mensajes.

Este enfoque resolvió los dos problemas planteados. Primeramente, ofrecía una forma natural de partir un programa muy complejo y, en segundo lugar, el mantenimiento pasaba a ser controlable. El primer punto es obvio ya que, al partir el programa en unidades informáticas paralelas a las físicas, la descomposición es automática. El segundo punto también se resuelve ya que, a cada iteración de simulación, el analista querrá cambiar o bien piezas enteras o bien el comportamiento de alguna pieza. En ambos casos la localización de los cambios está perfectamente clara y su alcance se reduce a un componente, siempre y cuando el interfaz del mismo no cambie. Por ejemplo, si se estuviese simulando un motor o coche, puede que se quisiera modificar el delco utilizado en la simulación anterior. Si el nuevo delco tuviera la misma interfaz (mismos inputs y outputs) o se cambiase sólo su comportamiento interno, nada del sistema (fuera del delco) estaría afectado por el cambio.

Pero, poco a poco, fue obteniendose otro beneficio muy importante, que es la razón principal por la que la industria informática se ha abocado a la orientación a objetos. Se trata de la reusabilidad. En el proceso de construcción de un programa se obtienen piezas para futuros programas. Avanzando algunas cifras, se puede indicar que los niveles de reutilización de software pasan del 5-15% en centros no orientados a objetos, a niveles por encima del 80%.

Para implementar estas ideas lo que se hizo fue crear un lenguaje para darle soporte, Simula-67, que continua utilizándose actualmente.

El siguiente paso se da en los años 70 en los Estados Unidos. Xerox tiene un centro de investigación en Plo Alto, donde trabajan en conceptos que puedan convertirse en productos industriales al cabo de 10 a 20 años. Así pues, en aquellos años contrataron a un joven llamado Alan Kay para que llevase a término las ideas que proponía en su tesis doctoral, la propuesta de construcción de un ordenador llamado Dynabook, adecuado para ser utilizado por niños. El ordenador no tenía teclado, la pantalla era sensible al tacto y la mayor parte de la comunicación era gráfica. Al desarrollar este proyecto se inventó el 'mouse' y los entornos gráficos. Al volver a encontrarse con una progra-mación compleja y experimental, como en el caso de Nygaard, decidieron crear un entorno y lenguaje llamado Smalltalk.

Smalltalk tuvo una gran difusión y cuando en los años 80 en ATT-Bell quisieron crear un sucesor al lenguaje C, incorporaron las principales ideas de Smalltalk y de Simula, creando el lenguaje C++. Puede afirmarse que se debe a este último la gran extensión de los conceptos de la orientación a objetos.

Conviene subrayar que el desarrollo que hemos descrito se refiere sólo a la evolución que ha tenido la orientación a objetos en el mundo de la ingeniería del software. Ha existido un desarrollo paralelo de los mismos conceptos en el mundo de la inteligencia artificial, donde el lenguaje CLOS, una variante de Lisp orientada a objetos, está enormemente extendido.

Principios

La orientación a objetos se basa en tres pilares básicos: - encapsulación y ocultación de la información - abstracción y clasificación

- herencia y polimorfismo

La encapsulación significa agrupar en una sola entidad ('caja') datos y operaciones sobre esos datos. Evidentemente todo programa es una encapsulación, pero por encapsulación queremos decir algo mas preciso: en concreto, cada componente ha de tener nada más que los datos relacionados con un tema y su manipulación. Por ejemplo cualquier programa de facturación puede leer directamente un registro de artículo y modificar el 'stock' al mismo tiempo que imprime la factura y modifica el saldo del cliente. Tenemos tres activitades sobre tres entidades diferentes en un único componente ('el progra-ma'). Este programa no tiene una encapsulación adecuada.

El concepto de ocultación de la información se refiere a que cada componente sabe lo mínimo posible de los otros y proporciona la mínima información posible sobre sí mismo. Por ejemplo, si en una aplicación se puede acceder al saldo de un cliente, es innecesario saber si el saldo está almacenado como un entero o un real o si se ha de ejecutar una rutina para obtenerlo. Sólo debe preocupar como pedirle al cliente su saldo y no como está representado internamente.

Desde hace muchos años, estos principios han estado disponibles en los lenguajes de programación, aunque su uso era optativo. La diferencia es que los lenguajes orientados a objetos dan soporte sintáctico a los dos conceptos, y que su uso es obligado en muchos lenguajes puros orientados a objetos.

El siguiente pilar es el de la abstracción y clasificación. Por abstracción entendemos que los módulos, a los que aplicamos la encapsulación y la ocultación citadas, sean representaciones abstractas de los conceptos que nos interesan. Es decir, que si hacemos una aplicación para una autoescuela, deberemos crear una entidad informática, que de momento podemos llamar módulo, para abstraer los hechos más característicos de los conceptos que estamos tratando: coche, alumno, matrícula, semáforo, etc. Hasta ahora, se habían considerado solamente los datos al diseñar la base e datos. Ahora deberemos hacerlo con todas las características de las entidades de nuestro modelo o dominio. Por ejemplo, si un cliente puede tener un descuento, deberemos asociar la

...