Si pensamos en las librerías, en cualquier lenguaje, ya sean módulos, paquetes u objetos, siempre alcanzamos una funcionalidad encapsulada dentro de una forma específica a la que se la puede llamar para realizar una acción. Pero esto cambia radicalmente en los frameworks, u entornos de desarrollo, ya que estos entornos, normalmente, realizan un cierto trabajo, y te permiten extender esa funcionalidad base, con ciertas reglas, a través de código que se escribe.

Se podría pensar en los frameworks como piezas de software que permiten agregar una funcionalidad extra desarrollada por el programador que usa el framework, a modo de addon, plugin o extensión. Pero no es eso. Las extensiones (o llámese como se quiera) son trozos de código, que opcionalmente se puede ejecutar en un programa completamente funcional. Como es obvio, ningún framework es completamente funcional sin agregar ningún código por parte del programador.

Por lo tanto, la inversión de control es más una base sobre la que construir un elemento, es nuestra arquitectura de soporte, mientras que la base sobre la que se programa un plugin es un elemento completo y funcional que se extiende mediante el plugin, pero que no depende de él.

Este es otro de los grandes elementos en los que se basa la Ingeniería del Software al decir que, lo importante, es la lógica de negocio o el sistema en sí que se quiere desarrollar, dejando la parte de arquitectura de soporte y el trasfondo sobre el que se ejecuta la solución al framework.

Si aún se tiene alguna duda, puede que con este ejemplo se disipen (o aumenten ), tomado del artículo de Martin Fowler comentado antes, tenemos un trozo de código en Ruby tal que así:

puts '¿Cómo te llamas?'
nombre = gets
procesa_nombre(nombre)
 
puts '¿Qué buscas?'
busqueda = gets
procesa_busqueda(busqueda)

En este trozo de código todo está bajo control, el sistema se ejecuta de forma lineal, pide la información en el momento en el que se le ha escrito y descrito y el código se ejecuta, secuencialmente, de forma predecible.

Ahora veremos otro ejemplo:

require 'tk'
 
root = TkRoot.new
nombre_etiqueta = TkLabel.new() { text "¿Cómo te llamas?" }
nombre_etiqueta.pack
 
nombre = TkEntry.new(root).pack
nombre.bind("FocusOut") { procesa_nombre(nombre) }
 
busqueda_etiqueta = TkLabel.new() { text "¿Qué buscas?" }
busqueda_etiqueta.pack
 
busqueda = TkEntry.new(root).pack
busqueda.bind("FocusOut") { procesa_busqueda(busqueda) }
 
Tk.mainloop()

Aquí hay una gran diferencia en el flujo de ejecución, ya que los mensajes se ejecutan en el orden que el framework los llama, según la interacción del usuario. En este caso, el framework controla la ventana, los eventos que se suceden sobre los elementos gráficos y, en el caso de que haya un evento, si hemos desarrollado código para atender a ese evento, es el framework el que llama a nuestro código. Eso es inversión de control.

Este autor, en su afán por facilitar dentro de lo posible el desarrollo de software para todo tipo, se ha introducido en las entrañas de lo que es el software de empresa típico y ha definido elementos, objetos, patrones y ayudas específicas que facilitan el análisis, diseño y programación en general de aplicaciones de este tipo. El libro es Analysis Patterns.

La obra nos introduce en el mundo de los patrones, los conceptos y modelos de los negocios e intenta dar una visión general del porqué estos patrones pueden ayudarnos a simplificar la creación de aplicaciones. A través de los capítulos, se van viendo, tema por tema, todos los aspectos que en toda empresa se suelen abordar: contabilidad, plannings, inventario, etc.

Como suele decir Richard Stallman: “para leer buen código hay que leer buen código“; y esta obra la considero un buen sistema de análisis para el que se quiera aventurar a realizar análisis de sistemas de información.