Estructuras de datos

Antes de comenzar con el detalle del desarrollo que indicaba en el artículo de estrategia con ILE voy a introducir un concepto que utilizo para el desarrollo de plantillas de código. Son el uso de estructuras de datos (Ds).

Parámetros, un problema para desarrollar plantillas.

Comentaba en el artículo que hecho referencia anteriormente que se podría desarrollar plantillas tanto para los módulos de presentación de pantalla como para los de acceso a base de datos y de lógica de negocio pero un problema a resolver para facilitar el uso de plantillas es el paso de parámetros entre programas, módulos o componentes.
La idea de tener plantillas es que tengan código invariable y ya probado que es independiente  de la funcionalidad que se esta desarrollando y que no hay que habría que tocar ni modificar. Pero ¿que pasa con los parámetros y el código probado para no tocar?

Imaginemos que tenemos un fichero X que tiene tres atributos (campos) y otro fichero Y que tenga cinco campos. Comentabamos que podíamos hacer una plantilla de componente para insertar registros a un fichero y que ese componente pudiera ser utilizado desde un modulo de presentación de pantalla Mod1 que en un caso haga el mantenimiento del fichero X y en otro Mod2 para el fichero Y.

La parte del código de los módulos de presentación de pantalla para llamar a insertar un registro cada uno en su fichero sería algo así

Parte del código de Mod1

. . . IdRegGenerado = Insertar_FileX(Campo1 : Campo2 : Campo3);

Parte del código de Mod2

. . . IdRegGenerado = Insertar_FileY(Campo1 : Campo2 : Campo3 : Campo4 : Campo5);

Así se presenta un problema a la hora de gestionar plantillas. Cada vez que se haga un proceso específico habría que cambiar las llamadas a TODOS los programas, módulos y componentes para poner los parámetros propios de cada uno. Y esto no parece muy bueno para la definición de plantillas.

La solución. Estructuras de datos. 

El objetivo es que los parámetros de llamada SIEMPRE sean los mismos y así no tener que "tocar" en la plantilla los parámetros de llamada a un programa, módulo o componente y en dichos fuentes tampoco tener que tocar los parámetros que recibe. 

Para ello utilizaré las estructuras de datos. Los parámetros serán estructuras de datos; así no hay que tocar los parámetros de llamada. Lo único que hay que hacer de una funcionalidad específica a otra, sería añadir más campos a la definición  de la estructura de datos y antes de la llamada, cargar los campos de esa estructura de datos.

Parte del código de Mod1

D DsAltaFic       DS                  Qualified      D   Campo1                       5      D   Campo2                       5      D   Campo3                       5  . . .          DsAltaFic.Campo1 = Campo1;           DsAltaFic.Campo2 = Campo2;           DsAltaFic.Campo3 = Campo3;            IdRegGenerado = Insertar_FileX(DsAltaFic);

Parte del código de Mod2

D DsAltaFic       DS                  Qualified      D   Campo1                       5      D   Campo2                       5      D   Campo3                       5       D   Campo4                       5      D   Campo5                       5 . . .          DsAltaFic.Campo1 = Campo1;           DsAltaFic.Campo2 = Campo2;           DsAltaFic.Campo3 = Campo3;           DsAltaFic.Campo4 = Campo4;           DsAltaFic.Campo5 = Campo5;           IdRegGenerado = Insertar_FileY(DsAltaFic);

Como vemos, aunque son dos componentes diferentes (insertar_FileX e insertar_FileY) que darán la misma funcionalidad (insertar un registro), ambos tienen el mismo número de parámetros, en este caso una estructura de datos con el mismo nombre pero que en cada caso tendrá un número de campos diferente.

En mis plantillas de fuentes Rpg, las llamadas siempre están definidas con estructuras de datos para evitar estar "tocando" los parámetros entre los procesos que llaman y los llamados.