Programación estructurada y orientación a objetos

Debido a que una forma habitual de realizar la partición en módulos consiste en agrupar las funciones que permiten operar con un determinado conjunto (o estructura) de datos, existe una analogía evidente con la programación orientada a objetos. De hecho, ésta puede verse como la continuación lógica de aquélla. Así pues, realizaremos una comparación entre ambas técnicas de programación, resaltando las semejanzas existentes entre ellas.

La mente humana utiliza patrones o modelos que faciliten la comprensión del complejo mundo real. Así, estos patrones mentales de comportamiento abstraen aquellas características de un elemento o situación necesarias para su comprensión ignorando los detalles que resulten irrelevantes. Este proceso es conocido como abstracción y resulta esencial en el razonamiento humano, ya que gracias a él podemos manejar sistemas de gran complejidad.

La abstracción ha sido un aspecto clave de la programación desde sus comienzos. Al principio, los programadores enviaban instrucciones binarias a los ordenadores. Posteriormente, se empleó el lenguaje ensamblador, que no es más que el resultado de un proceso de abstracción del código máquina y que nos permite representar secuencias de bits por símbolos más inteligibles e intuitivos denominados nemotécnicos.

El siguiente nivel de abstracción se alcanzó cuando se crearon las instrucciones definidas por el usuario, las macroinstrucciones que abstraían a las propias instrucciones. En un proceso de mayor abstracción surgieron los lenguajes de alto nivel (como Fortran, C, Pascal, Cobol, etc.), que evitan al programador tener que pelearse con el tan denostado código máquina.

La programación estructurada y la orientación a objetos constituyen los pasos finales de este camino, ya que permiten a los programadores escribir código sin necesidad de conocer los detalles de la implementación de funciones de una librería y objetos respectivamente. Su implementación permanece oculta a los programadores, liberándoles de los condicionantes que esto imponía.

De ese modo, un programador no necesita saber cómo se representan internamente los datos de un tablero de ajedrez. Tan sólo necesitará saber cómo mover, iniciar una partida o validar un determinado movimiento.

Lo realmente complicado de ambos paradigmas de programación es encontrar los modelos o patrones conceptuales correctos para el problema y no la implementación de los mismos. Realmente, el diseño adquiere la máxima importancia que no tenía en la  programación tradicional.