Desmontando a imperativo (Deconstruyendo imperativo)

Desmontando a imperativo (Deconstruyendo imperativo)

¡Compártelo!Share on FacebookTweet about this on TwitterGoogle+Share on LinkedInEmail to someone
· ·

Desmontando a imperativo

La programación imperativa o estructurada, cuya única diferencia básica es tener constancia de que existen las funciones, presenta tres pilares fundamentales.

  • Selección
  • Secuencia
  • Iteración

Con estos tres elementos se puede identificar claramente un programa imperativo (C, Java, .NET,...) independientemente de que implemente otros paradigmas (orientado a objetos, genérico…).

La selección, el clásico si, lo mencioné en un anterior mensaje, en este caso vamos a comentar la secuencia, que no es más que la limitación que presentan estos lenguajes al tener que ejecutar su código de manera secuencial.

El hecho de que el código se ejecute línea tras línea presenta serios inconvenientes, como el tan obvio de tener que llevar un control sobre el orden en que los acontecimientos se van a desencadenar en código, este hecho que podría parecer lógico y trivial desvirtúa en muchas ocasiones el resultado final del código.

Existen infinidad de ejemplos en los que el orden no es importante o no debería ser un impedimento a la hora de desarrollar, como el clásico ejemplo del menú, un menú se puede desarrollar de muchas formas diferentes, cortando los ingredientes en diferentes formas y alternando la elaboración de un plato a otro, no existe un orden concreto en sus elementos individuales.

No existe el concepto de tener que comprobar exhaustiva y meticulosamente si cada uno de los elementos previos ha sido realizado (¿he cortado este ingrediente?, ¿tengo que ir al almacén ahora o después?), simplemente el resultado final.

Similar en cierto sentido al funcionamiento de la inyección de dependencias, no existe tampoco el concepto de tener presente la relación entre objetos dependientes, el propio contenedor es capaz de crear el objeto resolviendo todas las dependencias necesarias, lo cual aísla al programador de estos detalles cuya única tarea recae en alimentar el contenedor con objetos.

Este hecho obliga al programador a ser excesivamente meticuloso a la hora de generar el código y tener presente infinidad de detalles intrascendentes que le apartan de la verdadera tarea que es desarrollar el concepto base de la aplicación, así como desarrollar la aplicación de la forma más eficiente y no dejarse perder en una red de puntos inconexos.

Este problema devenido de la herencia histórica es debido a que los lenguajes de programación se desarrollaron para que fueran fáciles de utilizar, y la mayor pate de todas las evoluciones posteriores fueron en esa dirección, lo cual implica simplificar el sistema a tal punto que cualquier programador con un CI positivo sea capaz de compilar.

Tanto la secuencia como la selección desembocan de forma combinada en la iteración o repetición de una sentencia de manera secuencial, o dicho de otra forma, la continuada repetición de un posible error debido a la esclavitud de un si o la dictadura de un código secuencial.

Nuevas tendencias asoman en un futuro no muy lejano y es posible que cristalicen en otras formas de desarrollo orientadas más a la funcionalidad y alejadas de la divagación de errores en código.

Firmado,

Yo, Arquitecto
Josu Uribe Sainz

 


 

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies. Más información sobre nuestras cookies, siga este enlace

ACCEPT