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
SIEM & PME : Comment construire la boîte noire de votre SI ?
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et accessible, pour anticiper, détecter et réagir efficacement aux attaques.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les Assises 2026 : encore plus d’énergie pour poursuivre le chemin
- Agents IA : arrêtons de leur confier nos secrets
- Ransomwares : l’extorsion vise désormais les salariés et leurs proches
- Veeam passe à la vitesse supérieure avec iResOps pour Microsoft 365
Articles les + lus
Continuer avec Exchange Server : quelles conséquences ?
Raccourcis Réseau et Navigateur : le kit de Diagnostic des Professionnels IT
Raccourcis PowerShell et Windows Terminal pour les Professionnels IT
Commandes Windows 11 : le Guide des Outils accessibles avec Win + R
Sécurité : une approche dans la durée avant tout
À la une de la chaîne Tech
- Continuer avec Exchange Server : quelles conséquences ?
- Raccourcis Réseau et Navigateur : le kit de Diagnostic des Professionnels IT
- Raccourcis PowerShell et Windows Terminal pour les Professionnels IT
- Commandes Windows 11 : le Guide des Outils accessibles avec Win + R
- Sécurité : une approche dans la durée avant tout
