Pensando en objetos

Allá por 1977, Alan Kay, creador del lenguaje orientado a objetos Smalltalk dijo

Es más fácil enseñar Smalltalk a niños que a programadores profesionales.

Lo cual puede parecer sorprendente a primera vista. Sin embargo, si pensamos que uno razona en el paradigma orientado a objetos (OO) en términos de objetos del mundo real y no de datos en memoria, que estos objetos (el coche de mi vecino, el balón de Manu, el sillón de papá…) se clasifican en clases de objetos (Coche, Balón, Mueble,…) y que estás clases, a su vez, se organizan en jerarquías como la del reino animal o vegetal, quizás entendamos porqué a un programador ‘tradicional’ le cuesta más cambiar de paradigma de programación que a un niño ‘sin prejuicios’. Si a esta forma de ‘ver el mundo’ le añadimos la visión de un programa no como secuencia de instrucciones, sino como una colección de objetos con vida propia que se envian mensajes entre sí para llevar a cabo ciertas tareas, como si de laboriosos enanitos se tratara, los niños ganan por goleada.

Aclaremos que aquí entendemos por programador tradicional a aquel que está habituado a trabajar con lenguajes imperativos, como C, Pascal o incluso C++ cuando no usas técnicas OO. El cambio de paradigma cuesta. Cuando la parte más importante de una aplicación es la comunicación entre sus diferentes componentes (objetos) y no tanto la algoritmia que resuelve las pequeñas tareas que, combinadas, darán lugar al resultado final deseado, resulta obvio ver que nos movemos en un terreno diferente al ‘tradicional’.

¿Y porqué tenemos que cambiar de paradigma de programación? Se supone que con un lenguaje imperativo podemos resolver cualquier problema que sea computable… Sí, podemos hacerlo, pero pagando un alto precio: la complejidad de la solución se volverá inmanejable. Es lo que ocurrió en el mundo del desarrollo de software hace un par de décadas: la llamada crisis del software, la cual, según algunos, es crónica (he aquí algunos ejemplos recientes).

¿Es el paradigma orientado a objetos la panacea para evitar los problemas que originaron la crisis del software? No, no lo es, pero ayuda en gran medida a aliviar los problemas relacionados con la estructura y mantenibilidad del software. Además de una metodología como esta, que no deja de ser una herramienta, hacen falta desarrolladores que sepan utilizarla correctamente.