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)
![Module de logique de gestion (ou « modèle ») (suite) Module de logique de gestion (ou « modèle ») (suite)](https://www.itpro.fr/wp-content/uploads/2014/09/2765031dad05bc8a7fdcc7d8a6bcca79.jpg)
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 : 5 erreurs de sécurité](https://www.itpro.fr/wp-content/uploads/2022/07/Guide-de-Securite-Office-365-les-5-erreurs-a-ne-pas-commettre-Expertise-DIB-France.png)
Microsoft 365 : 5 erreurs de sécurité
A l’heure où les données des solutions Microsoft 365 sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités ? Découvrez le Top 5 des erreurs à ne pas commettre et les meilleures pratiques recommandées par les Experts DIB France.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Stimuler l’innovation durable grâce à la transformation numérique et aux principes ESG
- Retour au bureau avec Copilot M365
- Les entreprises optent pour des solutions durables
- Le rôle clé du no-code/low-code dans la transformation numérique
- Le rôle de l’intelligence Artificielle dans le Cloud Computing
![Revue Smart DSI](https://www.itpro.fr/wp-content/uploads/2024/07/SMART-DSI-Numero-34-Juin-2024.jpg)