Bonjour à tous,

Contrairement au titre de cet article, il ne va pas s’agir ici de parler d’ABAP, mais de conception orientée objet de façon plus générale. Enfin pas si générale que cela car je ne vais aborder qu’un seul point, et ce point concerne le fonctionnement des méthodes.

C’est en fait un principe de bon sens : une méthode doit faire ce que l’on attend d’elle qu’elle fasse. Ni plus, ni moins. C’est aussi simple que cela. Mais si j’en parle aujourd’hui, c’est que ça ne l’est pas pour tout le monde. Pas toujours dans le feu de l’action, dans la pression des délais ou au détour d’une correction rapide.

Je suis récemment tombé sur une méthode publique censée contrôler l’alimentation d’un champ donné dans une table donnée. Et cette méthode retournait un booléen selon le résultat positif ou négatif du contrôle. Rien de plus simple, non ?
Seulement voilà, en plus de retourner un booléen, cette méthode mettait à jour un attribut de l’instance, lui-même utilisé dans (au moins) une autre méthode. Et l’appel de cette première méthode était effectué non pas pour exécuter le contrôle, mais pour pouvoir valoriser l’attribut d’instance…

Un tel fonctionnement doit être évité à tout prix ! La raison est simple : une méthode, a fortiori si elle est publique, doit pouvoir être utilisée sans que l’utilisateur ait connaissance de son fonctionnement interne. L’utilisateur qui appelle notre méthode pour exécuter son contrôle n’est pas censé savoir qu’elle va valoriser un attribut d’instance. Il y a un risque de dommages collatéraux sur le reste du processus impacté.

Attention, je ne parle pas ici d’un attribut qui serait valorisé en tant que buffer du résultat de la requête en base, un tel fonctionnement aurait tout son sens. Il s’agit dans notre cas de mettre à jour une variable qui n’est pas directement liée au fonctionnement attendu par la méthode.

C’est une question de sémantique. Si l’on souhaite mettre à jour un attribut lors d’une requête, alors il faut utiliser une méthode adéquate, qui sera indépendante de la méthode de contrôle de la valeur en base et/ou de l’attribut.

Encore une fois je le répète, il est trop dangereux de donner un rôle caché à une méthode. Une méthode rend un service précis, et un seul. Néanmoins cela ne veut pas dire qu’une méthode ne peut appeler d’autres méthodes. Sinon on ne s’en sortirait pas. Mais le nom de chaque méthode doit refléter son fonctionnement.

Si on ne devait retenir qu’une chose de tout ceci, ce serait : un code source ne doit pas être surprenant. Les noms doivent être explicites, les contenus tout autant.

P.-S. : je parle de méthodes dans le contexte orienté objet. Mais cela vaut tout autant pour le code ABAP procédural. Les sous-programmes doivent faire ce pour quoi ils ont été créés, uniquement cela, et ils ne doivent en aucun cas modifier ou même accéder aux variables globales du programme principal. S’ils ont des paramètres d’entrée/sortie, ce n’est pas pour rien.