Gérer des prototypes de procédures

un conseil judicieux, mais un peu limité face à  un
nombre de procédures sans cesse grandissant.



Tout comme les procédures cachent les détails du code qu’elles contiennent, une
bonne stratégie de gestion des procédures doit dispenser les développeurs d’une
connaissance précise de certains détails. Combien de fois se demande-t-on par
exemple quel est le membre copie qui contient des informations sur un prototype
de procédure particulier, ou encore quel programme de service il faut lier au
programme applicatif pour pouvoir bénéficier de la procédure. Ce serait intéressant
qu’un développeur n’ait pas à  se soucier de l’endroit où les programmes doivent
rechercher leurs informations de prototypes de procédures ou quels programmes
de services contiennent les procédures. C’est tout à  fait possible !



En tant que développeur d’applications, il est facile de trouver et de copier
les prototypes si l’on s’impose de garder tous les prototypes de procédures dans
un membre unique et de copier tous ces prototypes dans le programme concerné.
Après tout, le fait qu’un programme contienne des prototypes non utilisés ne nuit
nullement aux performances. En revanche, une grande quantité de code non utilisé
et sans inter-relation, rend les listings de compilation et les sessions de débogage
compliqués et confus. On peut bien entendu améliorer ce standard en ajoutant l’utilisation
de directives de copie conditionnelle. Le programme pourrait alors se borner à 
ne copier que les procédures qu’il utilise. Mais, même ainsi, on renonce à  la
modularité en gardant tous les prototypes dans un membre.





En utilisant une technique que j’ai baptisée copie conditionnelle indirecte, on
peut offrir aux développeurs la simplicité d’un membre copie unique pour obtenir
tous les prototypes, sans renoncer à  la modularité. C’est possible grâce à  la
copie imbriquée du RPG, qui permet de copier un membre qui à  son tour copie un
membre qui peut copier encore un autre membre, et ainsi de suite. La copie conditionnelle
indirecte permet aux applications de spécifier un membre copie de premier niveau
qui ne contient que les directives de copie ultérieure. Ce deuxième jeu de directives
copie à  son tour les informations dont l’application a besoin, d’où l’appellation
copie conditionnelle indirecte. La figure 1 présente un exemple de cette technique.
Il faut analyser cet exemple en tenant compte des considérations de conception
suivantes :



· Les membres sources du programme de service contiennent le source pour les prototypes
de procédures que les applications copieront.

· Le membre source Prototypes sert de membre copie de premier niveau et contient
les directives de copie conditionnelle de deuxième niveau qui copient les prototypes
de procédures à  partir du source du programme de service.

· Tous les programmes applicatifs désignent le membre Prototypes comme le membre
copie à  utiliser pour obtenir indirectement des informations de prototype de procédure.



Bien que ce ne soit pas la seule façon d’atteindre ce but, je choisis celui-ci
parce que je préfère garder les prototypes de procédures dans le source pour les
programmes de services qu’ils contiennent, plutôt que dans des membres copie distincts.



Le source commence par copier les spécifications de contrôle standard (en A).
Ces spécifications (figure 2) ne participent pas à  l’obtention des prototypes
de procédures, mais elles jouent un rôle important dans la création des programmes
applicatifs. Je reviendrai sur ces spécifications ultérieurement. Pour l’instant,
il suffit de savoir qu’elles existent.



En B dans la figure 1, on voit comment les développeurs ajoutent des prototypes
de procédures à  leurs applications. En utilisant la directive de copie conditionnelle
/Define, le programme établit les conditions nécessaires pour copier toutes les
procédures dont il a besoin. On peut observer la manière dont j’établis les conditions,
je place le préfixe  » Copy  » devant le nom du prototype de procédure. J’indique
ainsi clairement que la condition a pour but de faire copier par le compilateur
le prototype de procédure nommé. Les directives /Define sont suivies de la directive
/Copy qui effectue la copie.



Les développeurs n’ont jamais besoin de connaître précisément l’emplacement
réel des informations



Même s’il y a des prototypes de procédures dans de nombreux membres source, grâce
à  la technique de copie conditionnelle indirecte, il suffit de spécifier un membre
de copie unique, Prototypes. Ce membre contient des directives de copie conditionnelles
qui effectueront la copie de l’information de prototype réelle. On ajoute les
directives de copie conditionnelles appropriées au membre Prototypes quand on
crée des prototypes. Les développeurs n’ont jamais besoin de connaître précisément
l’emplacement réel des informations. Après la copie des prototypes, le programme
utilise simplement la directive /UnDefine pour supprimer les conditions précédemment
définies. Si on le souhaite, on peut confier la suppression des conditions au
membre copie plutôt qu’au programme applicatif. Il suffit de placer les directives
/UnDefine à  la fin des blocs de code auxquels les directives se réfèrent dans
les membres de copie. Jusqu’ici, on voit donc que pour qu’un programme applicatif
utilise un nombre quelconque de procédures, indépendamment de l’emplacement du
source de prototype, il suffit de définir ces procédures et d’indiquer Prototypes
comme le membre à  copier. Difficile de faire plus simple pour le développeur d’applications.



Voyons maintenant comment le membre copie Prototypes est construit. Prototypes,
figure 3, commence par établir une condition (en A) qui indique que le compilateur
est en train de copier des prototypes. Les programmes de services contenant les
prototypes copiés testent cette condition pour s’assurer que le compilateur ne
copie que les informations de prototypes. Les directives de copie pour les programmes
de service (Dates, Jobs, Messages et Objects) apparaissent respectivement en B,
C, D et E.



En regardant de plus près l’un de ces blocs de code (B), on voit qu’un test détermine
si l’une des procédures du programme de service Dates doit être copiée. Si oui,
le compilateur copie les parties pertinentes du membre source Dates. On notera
que, par conception, il n’y a qu’un passage au travers de Dates pendant la phase
de copie. Comme tous les prototypes désirés sont définis pour la copie, tous sont
copiés. Enfin, en F, la condition indiquant que le compilateur copie des prototypes
est supprimée.



Il ne reste plus qu’à  voir la manière d’agencer les programmes de service. Il
faut construire ces derniers en visant deux objectifs :



· Le programme de service doit compiler.

· Le programme de service doit fournir aux applications un moyen de copier des
informations de prototype.



Il faut donc créer des conditions telles que, dans un cas tout le code soit inclus,
permettant la compilation des programmes de service et dans un autre cas le code
référencé soit limité à  celui des prototypes de procédures. On peut y arriver
en segmentant le code en trois sections :



· le code précédant les prototypes de procédures

· le code constituant les prototypes

· le code suivant les prototypes



La figure 4 présente des parties du source du programme de service Dates contenant
les procédures de type date RtvDayOfWeekNbr, RtvDayOfWeekName et RtvDaysBetweenDates.
Les trois sections du programme de service apparaissent en A, B et C. Les prototypes
de procédures apparaissent en B, et chacun est conditionné individuellement pour
la copie. Le code en A et C est conditionné de telle sorte qu’il ne soit pas copié
quand un programme applicatif copie des prototypes. Le source en A et C n’est
inclus que quand la condition CopyingPrototypes n’est pas définie, c’est-à -dire
quand on compile le programme de service. On observe que les dernières lignes
du code en A sont des directives /Define, qui ordonnent au compilateur d’inclure
les prototypes quand il compile le programme de service.



En étudiant l’exemple de code, on voit bien qu’il est facile d’obtenir des informations
de prototype de procédure avec une copie conditionnelle indirecte. L’exemple fourni
n’est qu’une implémentation de la copie conditionnelle indirecte. On peut choisir
quelques variantes mieux adaptées à  son propre environnement.