Un exemple

se charge pas de la
logique de sélection des pièces, mais il
contrôle ce qui est fait une fois les
pièces sélectionnées. Ce genre de
modularisation exige une bonne planification
préalable pour répondre à  la question : comment les données
nécessaires seront-elles échangées
entre les procédures concernées ?
Pour garder l’exemple programme
aussi simple que possible, j’ai omis les
spécifications de fichier et toute la logique
de gestion de l’écran.
POPRINT utilise une gestion
d’écran classique pour entrer un nouveau
numéro de bon de commande
(PO). Puis il crée l’enregistrement
d’en-tête correspondant dans le fichier
PO. Une fois l’enregistrement d’en-tête
créé, POPRINT appelle GETPARTS
pour traiter la sélection des pièces
pour le PO. POPRINT passe aussi GETPARTS
au pointeur de procédure
contenant l’adresse de DTLPRINT.
DTLPRINT est une sous-procédure codée
en bas du POPRINT. C’est important
parce que GETPARTS ignore complètement
l’existence de DTLPRINT.
POPRINT indique à  GETPARTS quelle
sous-procédure il devrait appeler pour
traiter chaque pièce sélectionnée.
GETPARTS est un module dans un
programme de sous-fichier générique
qui affiche simplement une liste de
pièces, laissant à  l’utilisateur le soin
d’entrer une quantité. Comme GETPARTS
se trouve dans un programme
de service, il est facile de l’appeler à 
partir d’autres programmes. Il effectue
une boucle au travers des pièces sélectionnées
puis appelle le pointeur de
procédure que lui a donné POPRINT. Il
transmet alors le numéro de pièce et la
quantité sélectionnés. Rappelons que
GETPARTS n’a aucune idée de la routine
qu’il est en train d’appeler. Il doit
croire aveuglément que vous lui avez
fourni une adresse de procédure valide.
Dans ce cas, il appelle la procédure
DTLPRINT dans POPRINT. Une
fois que toutes les pièces ont été traitées,
GETPARTS se termine et retransmet
le contrôle à  POPRINT.
DTLPRINT est appelé par GETPARTS
pour chaque pièce sélectionnée.
Il ajoute chaque pièce au bon de
commande (PO) et imprime la ligne
détail. Après quoi, il redonne le
contrôle à  GETPARTS.
DTLPRINT n’est pas forcément une
sous-procédure. Nous pourrions le
créer comme un programme indépendant
et passer son nom comme un paramètre
de POPRINT à  GETPARTS.
GETPARTS appellerait alors le nom de
programme chargé dans cette variable.
C’est moins compliqué que d’utiliser
des pointeurs de procédures, mais
aussi bien moins efficace. Les appels de
pointeurs de procédures sont très rapides
et toute application avec une
modularisation extensive qui utilise
des appels de programmes est
condamnée à  des performances médiocres.
Les appels de procédures
s’exécutent beaucoup plus rapidement
et autorisent une modularisation extensive
sans payer trop cher en performances.
Le principal obstacle de la modularisation
avec des appels de
procédures est que les noms de procédures
sont codés en dur dans le programme
et pas suffisamment souples
pour ce genre d’utilisation générique.
C’est pourquoi on utilise les pointeurs
de procédures. Ils permettent des appels
prototypés fondés sur une adresse
plutôt que sur un nom. Les prototypes
génériques définissent des arguments
transmis à  une procédure, mais pas la
procédure elle-même.
Examinons le code. POPRINT (figure
2) inclut du code standard que
tous les programmes dans l’application
contiendront. La structure de données
SYREFER définit tous les champs standard
dans l’application. Le fait d’inclure
cette structure de données dans
tous les programmes permet des définitions de champs communes avec le
mot-clé LIKE() et évite des tailles de
champs codées en dur. Le /COPY de
Utilities à  partir de QPROTOSRC obtient
toutes les définitions standard nécessaires
pour le code utilitaire, qui inclut
le programme de service
GETPARTS. Le prototype DTLPRINT
est défini avec deux paramètres : un
numéro de pièce et une quantité.
Après avoir établi toutes les définitions,
voyons les calculs.
Cet exemple est très simple. Le
premier calcul active (on) *INOF. Cela
oblige l’impression des en-têtes du
rapport quand la première ligne détail
est imprimée. Le programme appelle
GETPARTS, transmettant ces deux paramètres
: le numéro de bon de commande
(PO) et l’adresse de DTLPRINT.
GETPARTS (figure 3) affiche un listing
sous-fichier des pièces et permet
aux utilisateurs de sélectionner une
quantité des pièces qu’ils ont choisies.
Le programme effectue une boucle en
lisant chaque pièce sélectionnée puis
appelle une procédure nommée PROCESS,
en lui transmettant le numéro
de pièce et la quantité comme paramètres.
C’est là  que ça devient intéressant.
Il n’y a pas de sous-procédure nommée
PROCESS ! C’est simplement un
« place holder » ou un « proxy ». PROCESS
est un prototype générique qui
définit une procédure externe d’après
le pointeur de procédure ProcAddr,
qui a été reçu comme second paramètre
à  partir de POPRINT. Le prototype
PROCESS sert de remplacement à 
toute procédure réelle que GETPARTS
doit appeler. Chaque programme applicatif
qui appelle GETPARTS lui fournira
aussi le pointeur de procédure
pour la routine qu’il doit appeler pour
traiter les pièces sélectionnées. Cela
permet d’utiliser GETPARTS par une
grande variété d’applications avec peu
de temps de coding et pratiquement
aucun besoin de tester la logique de
sélection des pièces, parce que ce
code de gestion d’écran a été écrit précédemment
et reste inchangé.
DTLPRINT reçoit une pièce et une
quantité sélectionnées. Il examine
*INOF pour voir s’il faut imprimer des
en-têtes, puis il imprime l’enregistrement
détail. Cela fait, le contrôle revient
à  GETPARTS, qui lit l’enregistrement
suivant et appelle à  nouveau
DTLPRINT. L’opération se répète jusqu’à 
ce que toutes les pièces aient été
lues et traitées.