Programación supermodular

Manuel Calero Solís 24.abr.2002

«Cuanto más se dividen los obstáculos son más fáciles de vencer«.
Concepción Arenal (1820-1893); escritora y socióloga española.

Hace algunos meses en una conversación a través del messenger con mi amigo Paco, empezamos a hablar de las distintas técnicas de programación y hablamos de una que yo llevaba tiempo practicando pero sin haberla aprendido de ningún libro, solo llegando a ella por la experiencia propia.

Posiblemente tenga un nombre, posiblemente usted ya la este practicando,  y posiblemente este en los libros, pero como a mi me ha valido de mucho la expongo aquí.

Yo la llamo programación «Supermodular». No espere nada revolucionario, es un nombre que se me ha ocurrido y creo que no la define muy bien pero es el nombre que he encontrado.

¿De que se trata? Se trata de crear muchas funciones o metodos que hagan cálculos mínimos e ir subiendo hasta obtener el resultado deseado.

Me explico,  o lo intento,  con un caso concreto: imagine que estamos trabajando en un programa, mas concretamente en un modulo del programa, por ejemplo en el calculo de una factura, y decimos mentalmente, «Total de factura es igual a unidades por precios de tantas líneas como contenga la factura, mas el I.V.A.». Esto seria de manera simple y sin tener en cuenta muchos otros factores, descuentos, comisiones, etc., bueno estamos en un ejemplo.

 Como resolvemos el problema.

Codigo 1
//-------------
Metodo Total()
nTotalFactura := 0
while cCodigoFactura == cCodigoFacturaLinea
   nTotalFactura += nUnidades * nPrecio
end while
nTotalFactura += nTotalFactura * nPorcentajeIVA / 100
return ( nTotalFactura)
//--------------

¿Pero que tiene de malo este código?

En principio nada o mucho según se mire, el problema esta resuelto pero no hemos pensado en el futuro, en lo que pasará mañana o a mas tardar pasado.

Mañana ha llegado, y nuestro jefe nos dice que han decidido que ahora las facturas deben de soportar Cajas, o sea que puedas facturar por Cajas. Fácil ¿ no ?.

Codigo 2
//------------
Metodo Total()
TotalFactura := 0
while cCodigoFactura == cCodigoFacturaLinea
   nTotalFactura += nUnidades * nCajas * nPrecio
end while
nTotalFactura += nTotalFactura * nPorcentajeIVA / 100
return ( nTotalFactura)
//--------------

El tema esta resuelto, pero hemos vuelto a hacerlo mal. Hemos resuelto el calculo de la factura pero debemos de tocar ahora todos los informes donde se nos pedían las unidades vendidas de una factura, y todos los gráficos, toda la impresión de la factura, y todo lo que mantenga una relación directa con la factura.

¿Qué propongo? Supermodular o dicho de otra manera menos rara: hacer funciones o métodos por cada dato que se necesite para hacer un calculo superior o por cada dato que será empleado en otra parte del programa. Pasemos a la practica.

Codigo 3
//--------
Metodo nUnidades()
Return ( nUnidades )
//-------
Metodo nPrecio()
Return  ( nPrecio )
//-------
Metodo nTotalLinea()
Return ( nUnidades() * nPrecio() )
//-------
Metodo nBaseFactura()
nTotalFactura := 0
while cCodigoFactura == cCodigoFacturaLinea
   nTotalFactura += nTotalLinea()
   skip
end while
return ( nTotalFactura )
//-------
Metodo nIva(nTotalFactura)
nIva := nTotalFactura * nPorcentajeIVA / 100
//-------
Metodo Total()
nTotalFactura := nBaseFactura() + nIva( nTotalFactura )
return ( nTotalFactura)
//--------

Si ahora me proponen el cambio en el calculo de las unidades se me pone una sonrisa de oreja a oreja y contesto a mi jefe ‘sin problemas jefe’

Codigo 4
//----------
Metodo nUnidades()
Return ( nUnidades * Cajas )
//----------

Pasado mañana mi jefe dirá que nuestra factura debe soportar el punto verde, ‘ ningún problema jefe’.

Codigo 5
//----------
Metodo nPrecio()
Return ( nPrecio + nPuntoVerde )
//----------

Y todo el programa saldrá funcionando, sin más problemas. Como veis la idea es muy simple lo verdaderamente complicado es saber que cálculos debemos de atomizar y cuales no, como norma todo aquellos datos que sospechéis van a ser utilizados en otras partes del programa, por ejemplo, es muy probable q necesitemos durante la vida de nuestro programa saber el numero de unidades facturadas de un determinado producto, ese dato nos lo da el método nUnidades(), y esta filosofía trasladarla a todo el programa.

Si algo he aprendido es que merece la pena pararse 30 min. sobre lo que vamos a hacer. Antes de codificar debemos coger un papel en blanco y pintar, meditar y reflexionar lo que se desea antes de escribir una sola línea de código, lo he aprendido pero a veces aun me precipito y lo pago siempre.

Saludos.

Fivewin no necesita un IDE, necesita un Glade

Dentro de la comunidad de desarrolladores que usamos Fivewin el tema del IDE ha sido siempre recurrente. Cada cierto tiempo aparece uno o varios mensajes en el foro de Fivetech sacando el tema a relucir y pidiendo que de una vez se termine el dichoso IDE. Hace poco tiempo Manuel Mercado, miembro destacado de la comunidad de desarrolladores, lanzó un guante con el proyecto VisualFivewin, y a raíz de los trabajos que ha realizado no pongo en duda de que sea capaz de llevarlo a cabo. Antes de seguir quiero dejar claro mi apoyo a Manuel en este proyecto y que he realizado la aportación para suscribir el proyecto porque pienso que una herramienta de este tipo va a ser beneficiosa para la comunidad de desarrolladores.

A mi nunca me han gustado los IDE, principalmente porque vengo de la escuela de la programación imperativa donde un programa tiene un principio y un final. Un IDE lo que hace es encapsular el código de los eventos de los widgets de un formulario con el formulario en sí, de manera que todo el proceso de diseño de formularios y la creación del código se realiza desde un entorno cerrado y que no hay manera de desenlatar. Además esto lleva a una micro fragmentación del código del programa: cada evento asociado a cada widget guarda su código por separado y es prácticamente imposible ver la secuencia lógica de las acciones que realiza el programa.

En Fivewin las cosas se han hecho tradicionalmente de otra manera. Usamos el editor de recursos de Borland – Resource Workshop – para dibujar los formularios de nuestra aplicación y con un editor de código definimos el comportamiento de estos controles. A mi entender esto es fantástico, pues por una parte tenemos una herramienta – hay que reconocer que un tanto anticuada – para pintar los formularios y por otra tenemos nuestro código que podemos leer y analizar secuencialmente aunque se trate de eventos asociados a los widgets de un formulario y que se pueden disparar en cualquier orden. El editor de recursos guarda los recursos como archivos DLL o RC y Fivewin se encarga de reproducirlos los formularios en tiempo de ejecución y de que se comporten de acuerdo al código que nosotros hayamos creado.

En gnome han planteado un entorno de desarrollo muy similar al que utiliza Fivewin, pero añadiendo una capa más. Todo el entorno gráfico esta realizado sobre las librerías GTK y existe una herramienta que sirve para crear formularios que con los widgets de GTK. Esta herramienta se llama GLADE y existen las librerías libglade que al enlazarlas con una aplicación permite que la aplicación reproduzca los formularios que se han creado con GLADE. Por si fuera poco GLADE permite almacenar los formularios en formato XML y libglade se puede enlazar con cualquier compilador que soporte interfaz con el lenguaje C. Asi desde casi cualquier lenguaje de los disponibles para gnome – C, perl, python,… – podemos utilizar un formulario hecho con GLADE. GLADE también es capaz de generar código en para distintos lenguajes de programación como C, C++, Ada,… En resumidas cuentas la idea es tener una herramienta independiente para crear el aspecto de la aplicación y otra separada para definir su comportamiento. A raiz por lo visto con gnome2 este enfoque es muy bueno. Parece que hay un proyecto para migrar GLADE a Windows de la misma manera que se está haciendo con GTK, esto es algo que habrá que seguir atentamente.

Sinceramente creo que la filosofía de separar la creación de los formularios del código que definirá su comportamiento tiene muchas ventajas sobre la aproximación de un IDE cerrado. Hasta ahora Fivewin no ha tenido un IDE y sinceramente pienso que no le hace falta. Mejor sería contar con algo parecido a GLADE.