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
Mac en entreprise : le levier d’un poste de travail moderne
Ce livre blanc répond aux 9 questions clés des entreprises sur l’intégration du Mac : sécurité, compatibilité, gestion, productivité, coûts, attractivité talents, RSE et IA, et l’accompagnement sur mesure proposé par inmac wstore.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- L’IA amplifie les risques sur les API
- Fuites de données : la France, 2ème pays le plus touché au monde début 2026
- Nomios accélère sur la cybersécurité industrielle avec un SOC renforcé et une Factory OT immersive
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
