Codes appelants, codes réalisants

images/whitebelt.png

En considérant qu’une fonction a un aspect "réalisation" d’un coté et un aspect "utilisation" de l’autre on touche du doigt un principe fondamental: la séparation entre "code réalisant" (le code détaillé qui décrit le fonctionnement) et "code appelant" (le code qui utilise la fonction sans rentrer dans les détails de la réalisation).

On a ici une séparation des tâches.

Le code réalisant a été écrit par quelqu’un qui a étudié un problème et, doit savoir comment le formaliser et écrire les instructions correctes qui traitent ce problème.

Le code appelant n’a pas besoin d’avoir le "comment" du code: il doit avoir une connaissance de surface du service rendu et invoquer le code avec les paramètres requis.

Pour avoir un code de qualité il faut systématiquement se mettre dans la position où ces aspects sont traités par des programmeurs différents. On va donc réfléchir en détail sur le contrat qui va lier ces deux programmeurs.

Quelles sont les obligations de l’un et de l’autre?:

[Note]Le cas des erreurs

Prenons par exemple le code des intérêts composés que nous venons de voir.

Il y a des contraintes supplémentaires qui ne sont pas complètement spécifiées si on s’en tient juste aux types double et int. Par exemple il serait erroné de passer des valeurs négatives! Pour rendre le code robuste il faut se prémunir contre ce genre d’erreur (très souvent involontaires de la part du code appelant).

Le programmeur réalisant a le choix entre deux stratégies:

  • créer de nouveaux types qui seront utilisés par le code appelant et qui garantiront une plage de valeurs correctes pour les paramètres (par ex. un type entier positif dans une plage de valeurs).
  • mettre dans le code réalisant des instructions de test de la validité des paramètres. Refuser l’exécution si nécessaire et prévenir le code appelant. Les modalités de cette gestion des erreurs est malheureusement un point trop souvent négligé dans les codes et nous y accorderons beaucoup d’importance.

Si, a priori, on sait quels peuvent être les programmeurs appelants on peut avoir des stratégies différentes (en particulier du point de vue de l'évolution des codes dans le temps):

Les langages de script (comme jshell) sont souvent conçus et utilisés pour des petites réalisations et des tests rapides qui ne nécessitent pas des protocoles lourds entre programmeurs (la plupart du temps programmeur réalisant et programmeur appelant sont la même personne).

Un langage comme Java est, au contraire, organisé pour permettre une organisation professionnelle qui implique la participation de plusieurs intervenants. A partir de maintenant nous nous focaliserons sur Java pour les codes réalisants et nous ne conserverons Jshell que pour des petits codes de test.