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
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Ready For IT 2026 : quand l’accélération de l’innovation redessine les priorités des décideurs IT
- Microsoft Build 2026 : industrialiser l’IA agentique dans les environnements d’entreprise
- IA et souveraineté des données : les entreprises françaises redéfinissent les infrastructures IT
Articles les + lus
Computex 2026 : 5 signaux forts à retenir
La chaîne d’approvisionnement, point de rupture récurent du SI
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
Analyse Patch Tuesday Mai 2026
À la une de la chaîne Tech
- Computex 2026 : 5 signaux forts à retenir
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- Analyse Patch Tuesday Mai 2026
