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

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

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

La figure 3 démontre le chargement en mémoire des données d’un client. Chaque routine de mon programme de service suit un modèle semblable à celui de la figure 3 :

1. Appeler la procédure Init() pour initialiser le module, dans le cas où cela n’a pas déjà été

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

fait (A en figure 3).

2. Conduire la logique de gestion dont la routine est chargée.

3. En cas d’erreur, appeler une procédure qui stocke « la dernière erreur survenue » et un code d’erreur correspondant (B). Je reviendrai bientôt sur ce point.

4. Si une erreur peut se produire dans une sous-procédure, cette dernière doit renvoyer un code d’erreur pour indiquer cela à l’appelant. Je préfère généralement renvoyer un indicateur mis à *ON (réussite) ou *OFF (échec). Lorsque des « champs » sont échangés entre la logique de gestion et la logique d’affichage, j’utilise une routine « getter » ou « setter », au lieu d’accéder directement aux champs du programme de service. Je peux ainsi valider les champs au fur et à mesure qu’ils sont définis, en plaçant la logique de validation dans le module de gestion, c’est-à-dire à sa vraie place. La figure démontre un getter (A) et un setter (B) pour le nom du client. En plus de fournir une couche de protection aux champs de mon application, Les getters et setters me donnent la maîtrise de la rétrocompatibilité. Ainsi, si je veux augmenter le champ nom du client à 50 caractères, je peux réécrire mon getter et setter comme dans la figure

5. Les éventuels programmes pré-existants appellent les anciennes routines getName() et setName(), et donc ils continuent à fonctionner comme à l’accoutumée (inutile de les recompiler). D’un autre côté, les nouveaux programmes qui veulent bénéficier de l’espace supplémentaire peuvent utiliser les routines getNameLong() et setNameLong(). Avec cette stratégie, seul le programme de service CUSTR4 est à recompiler quand je change ma structure de champ. Tous les getters et setters ne traiteront pas un champ unique. J’essaie de grouper les données circulant dans les deux sens, dans une sorte d’unité logique.

Par exemple, les procédures cust_getAddress() et cust_setAddress () de la figure 6 acceptent une structure de données comme paramètre. La structure de données me permet de passer l’adresse entière comme un paramètre unique. Je définis un modèle pour la structure de données et place cela dans un copybook avec les prototypes pour les sous-procédures, et j’utilise le mot-clé LIKEDS pour faire une copie locale de la structure de données là où elle est nécessaire.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010