Où est donc le problème ?

de programmes qui doivent lire et écrire des données client. Si je veux changer mon fichier client, chaque programme écrit de la sorte devra être analysé, modifié et retesté !

Que se passe-t-il quand je veux modifier des clients provenant d’un programme différent ? Peut-être que quand une commande est placée dans mon programme de saisie de commandes, elle devrait automatiquement afficher l’écran de modification afin que l’opérateur puisse vérifier (et, si nécessaire, changer) le nom et l’adresse du client. Maintenant, je dois modifier mon programme afin qu’il reçoive le numéro de client comme paramètre au lieu de le demander sur le second écran. Ou peut-être devrais-je écrire un programme « edit » entièrement nouveau séparé de celui-ci. Après quoi, j’aurai deux programmes à maintenir et deux endroits où modifier ma logique en cas de changements de stratégie.

Et si ma société décide d’accepter des commandes sur le Web? Dois-je écrire encore un autre module de modification de clients ?

Il est certain que d’autres applications, outre le programme de maintenance, extrairont aussi le nom et l’adresse d’un client. D’où l’idée de réutiliser ces parties de mon programme sans être obligé de les réécrire à chaque fois. Bien sûr, je pourrais copier et coller le code d’un programme dans un autre, ou même utiliser la directive de compilateur /COPY pour rassembler différents morceaux du programme, mais je me retrouve quand même avec un grand nombre d’objets programmes utilisant tous le même code. Si je modifie le code dans un endroit, je dois le modifier partout ailleurs pour que les règles de gestion s’appliquent de manière homogène. Dans le cas de /COPY, si je le change, je dois tout retester sous peine de voir un programme défaillir.

Quand tout changement exige beaucoup d’analyse et de nouveaux tests, il y a un problème. Votre système est trop rigide. Vous craignez tellement de perturber le code existant que vous répugnez à effectuer des changements pourtant bénéfiques. C’est le monde à l’envers : l’entreprise subordonne ses règles de gestion aux contraintes informatiques, plutôt que l’inverse.