Module de logique de gestion (ou « modèle »)

De la même manière, si je veux que la logique de gestion soit réutilisable, il faut la dissocier de la logique d’affichage. La logique du contrôleur assure le passage des données entre elles. La logique globale est certes la même, mais le modèle a beaucoup changé. La partie la plus réutilisable du nouveau design est la logique de gestion. Quand j’écris ma logique de gestion, je suis un modèle tel que celui-ci :

1. La logique de gestion est constituée de nombreuses routines individuelles.

2. Les routines individuelles ont toutes des listes de paramètres bien définies. Les variables globales ne sont jamais accessibles de l’extérieur de la logique de gestion elle-même. De sorte que je ne dois changer ou retester les programmes appelants que si je change les listes de paramètres elles-mêmes.

3. Une procédure Init() et une procédure Done() font la mise en place et le nettoyage respectivement pour le programme de service. Elles sont toujours appelées par les autres routines dans le même module pour l’initialisation et le nettoyage.

4. Les procédures Init() et Done() peuvent aussi être appelées par l’appelant si ce dernier a besoin de contrôler quand les fichiers du programme de service sont fermés et quand les variables internes sont redéfinies. Généralement, j’utiliserais les groupes d’activation pour cela, mais, pour des raisons de performances, l’appelant doit parfois pouvoir le contrôler directement, aussi tous mes programmes de service mettent les routines Init() et Done() à la disposition de l’appelant.

5. Le reste des routines ne traite qu’une fonction de gestion à la fois. Que faites-vous avec des données client ? Vous les chargez en mémoire, vous lisez les informations les concernant, vous créez des informations les concernant, vous les sauvegardez sur disque. Chacune de ces actions est une routine que l’on peut appeler indépendamment. J’utiliserais cette même logique de gestion pour tout programme sur mon système qui travaille avec les données client. Pour cette raison, j’aurai d’autres routines dans mon programme de service outre celles utilisées par le programme de maintenance que je démontre dans cet article. Ainsi, il pourrait y avoir une routine chargée de calculer le dernier solde d’un client ou de donner la date de sa dernière commande.

Chaque fois que j’écris un module, je lui donne un nom en rapport avec sa fonction. Dans le cas présent, il s’agit de clients, donc je le baptise CUST. Dans mon site, j’ai instauré une norme stricte : tous les noms de modules se terminent par un suffixe de deux caractères indiquant le langage dans lequel ils sont écrits. Par conséquent, mon module s’appelle CUSTR4.

Après avoir écrit du code modulaire pendant un certain temps, vous vous retrouvez avec une multitude de routines différentes dans divers programmes de service. Si vous n’y prenez garde, il peut même y avoir deux modules ayant chacun une routine de même nom, source de conflit. Imaginez un peu la maintenance ! C’est pourquoi je préfixe toujours chaque sous-procédure et tout ce qui peut être utilisé de l’extérieur du module lui-même, avec le nom du module, mais sans le suffixe de langage. Dans cet exemple, tous les noms de sousprocédures, structures de données, etc., commenceront par cust_. Et donc j’ai une procédure cust_init() pour initialiser le module, une procédure cust_done() pour nettoyer le module, une procédure cust_load() pour charger un nouveau client en mémoire, une procédure cust_get Name() pour extraire le nom d’un client, et ainsi de suite.

La figure 2 montre les routines qui initialisent et nettoient mon module. Ici, j’utilise ces routines pour ouvrir les fichiers utilisés dans le module. Dans un module plus complexe, il y aurait beaucoup d’instructions open (A en figure 2), chacune ouvrant un fichier différent. Une fois tous les fichiers ouverts, j’appelle l’API CEE4RAGE (B), qui ordonne au système d’exploitation d’appeler automatiquement ma procédure cust_done() quand le groupe d’activation se termine. Ainsi, si le contrôleur ne veut pas nettoyer le module, ou si quelque chose empêche le contrôleur d’effectuer son travail, le système d’exploitation appelle quand même ma routine de nettoyage.