Los conceptos fundamentales del diseño y la programación orientada a objetos han sido desarrollados hace más de treinta años, pero en los últimos diez ha tenido un crecimiento vertiginoso en la industria de desarrollo de software, merced a los progresos en velocidad y capacidad de procesamiento, junto con la necesidad de creación de software de alta complejidad. A la luz de los pasos del hombre en sus métodos para la construcción del conocimiento, encontramos que la programación ha recorrido en los sesenta años de su existencia un camino similar.
“Sospecho, sin embargo, que no era muy capaz de pensar. Pensar es olvidar diferencias, es generalizar, abstraer.”
Funes, el memorioso, Jorge Luis Borges
En los últimos treinta años, la informática ha realizado avances notables con respecto al hardware, las comunicaciones y las capacidades multimediales de las computadoras. Sin embargo, en el plano del desarrollo de sistemas complejos –salvo contadas excepciones– las herramientas elaboradas no usan las capacidades de simulación y emulación que convierten una computadora en un laboratorio virtual de infinitas posibilidades de creación.
A fines de la década del 60, Alan Kay creó la Dynabook, convencido de que la simulación es una herramienta notable para la comunicación de ideas y que una computadora debería ser el contenedor de todos los medios de expresión en los que uno pudiera pensar, es decir, un meta-medio. La Dynabook debía de ser un dispositivo portátil, con red inalámbrica y pantalla plana, entre otras cosas. Este dispositivo funcionaría como un "amplificador de la mente" y como lugar donde un usuario concentraría toda la información que consume y que genera. En un contexto en el que las computadoras eran grandes máquinas de costo altísimo, de uso privativo de grandes corporaciones, pensar en una computadora personal con estas características era dar un enorme salto hacia el futuro.
Guiados por esta visión, un grupo de referentes de la informática (Alan Kay, Dan Ingalls, Adele Goldberg, etc.) crean Smalltalk, un ambiente de objetos de donde surgen "la mayoría de las cosas buenas relacionadas con las computadoras personales (incluido el propio nombre)"1.
Una lista, no completa, de los aportes de este proyecto al desarrollo de la informática son:
-
El concepto de la Computadora Personal
-
El paradigma de objetos
-
Smalltalk
-
Interfaces de usuario gráficas
-
Uso del mouse
-
Drag & drop (Arrastrar y arrojar)
-
Menúes despegables
Curiosamente, el proyecto y la filosofía Smalltalk surgieron con la misma idea: crear un entorno en el cual el proceso de simulación en una computadora fuera equivalente al proceso de pensamiento, de comprensión, de modelización humana. Si, finalmente, el aprendizaje no es más que una modelización mental acotada de un Universo infinitamente complejo y caprichoso, la computadora tenía que presentar un ambiente similar para poder utilizarla como un laboratorio virtual altamente manipulable. Es decir, entendemos al proceso de construcción de software como un proceso de modelización análogo al proceso que realiza un científico al tomar un espacio acotado del universo en el que vivimos, en un conjunto acotado de objetos y propiedades, que permita encontrar un modelo que luego pueda ser aplicado no sólo al conjunto de datos que utilizó para su estudio, sino también a otros casos posteriores que se encuentren dentro de la cota de su estudio.
En el proyecto Smalltalk aparecen conceptos que hoy en día están presentes en todos los ambientes de creación de software: objetos, atributos, clases, mensajes y métodos. Objetos, como aquellos elementos que entran en juego en el sistema que estoy modelando (por favor, pensar en sistemas como algo más amplio que un programa en una computadora). Atributos, como las características que me interesa representar de cada objeto para el recorte que hago del universo. Clases, como el agrupamiento de objetos con características y comportamientos comunes. Mensajes, como la forma de comunicarse y de solicitar colaboración que tienen los objetos entre sí. Y métodos, como la descripción de la respuesta de un objeto a un determinado mensaje.
Volviendo al concepto de clases, cuando el diseñador se encuentra con un conjunto de objetos que comparten los mismos atributos y el mismo comportamiento (por ejemplo, cada uno de los empleados de una empresa donde se está construyendo un sistema de jornales; cada uno de los productos que produce una fábrica donde se está realizando un sistema de control de stock), utiliza el mecanismo de clasificación para abstraer estas propiedades y comportamiento. De esta forma, la construcción de la clase le permite generar una suerte de “plantilla” a partir de la cual puede construir los objetos que forman parte del sistema. Esta “plantilla” es un modelo recortado que toma únicamente las propiedades y comportamiento que le interesan para el sistema que está modelando en ese momento.
En el proceso de clasificación nos encontramos frecuentemente con clases que comparten algunas características comunes. Por este motivo, en los ambientes de objetos podemos construir clases superiores o abstractas, que encapsulan el comportamiento común, para que el conjunto de clases con características comunes hereden de la clase abstracta dichas propiedades. Al mecanismo por el cual una clase recibe comportamiento y propiedades de una clase superior, se le llama Herencia. Por ejemplo, en el caso de la clasificación de los vertebrados, podemos encontrarnos con la clase Mamíferos. Todas las subclases de Mamíferos heredan las propiedades y el comportamiento que le corresponde a los objetos que pertenecen a la clase Mamíferos. Por lo tanto, los Carnívoros, los Roedores, los Primates, por nombrar algunas de las subclases de Mamíferos, heredan la propiedad de tener mamas, de tener sangre caliente, etc. A su vez, la clase Carnívoro tiene la subclase Perro, la cual hereda los atributos tanto de Carnívoro como de Mamífero. Es decir, cada subclase es una especialización de la clase superior.
Habitualmente, en el diseño frecuente de modelos similares, comenzamos a encontrar estructuras de clases análogas entre los diferentes modelos. A partir del ejercicio de diseño, podemos desarrollar un conjunto de clases vinculadas entre sí, que con pequeñas modificaciones, nos permitan desarrollar soluciones para problemas en ámbitos similares. A esta estructura de clases se la denomina Framework. Sólo el diseño reiterado de modelos similares nos permite encontrar este tipo de estructuras. Por ejemplo, si un desarrollador realiza un modelo del tateti, del ajedrez, del sokoban, del teg, probablemente encuentre un nivel de abstracción superior, los juegos de tablero, que le permita construir un conjunto de clases que con una pequeña adaptación permita diseñar cualquier juego de tablero. Ha encontrado un framework para juegos de tablero. Existen frameworks para sistemas contables, para sistemas de control de producción, para reglas de negocios, etc.
Yendo a un nivel de abstracción más alto aún, en todos los desarrollos de sistemas hay un conjunto de problemas que se presentan en forma sistemática. Luego de años de trabajo, los desarrolladores han encontrado estructuras de clases que permiten presentar una solución efectiva, económica y probada para estos problemas. A estas soluciones se las denomina Patrones de diseño.
Habiendo presentado (en forma harto resumida) los conceptos fundamentales del diseño orientado a objetos, podremos mostrar donde encontramos los métodos de inferencia tradicionales de la ciencia en el proceso de construcción del software.
