Certains d’entre vous connaissent sûrement la loi de Demeter, mais un petit rappel ne fait jamais de tort :

La notion fondamentale est qu’un objet devrait faire aussi peu d’hypothèses que possible à propos de la structure de quoi que ce soit d’autre, y compris ses propres sous-composants.

Vous allez me dire : « C’est bien beau la théorie, mais en pratique ça s’exprime comment? » Voici donc un exemple : J’ai un objet « Auto » et je veux savoir si l’auto est en marche. Code qui ne respecte pas la loi :

auto.getMotor().getState().isRunning();

Code qui respecte la loi :

auto.isRunning();

Dans l’exemple ci-dessus, le respect de la loi rend d’abord le code vraiment plus simple à lire. De plus, le code est plus facile à maintenir. En effet, si je change le design et si l’état “Running” n’est plus au niveau du moteur mais plutôt au niveau des roues, vous devez changer auto.getMotor().getState().isRunning() par auto.getTire().getState().isRunning(), alors que si vous aviez respecté cette loi, vous auriez eu juste à changer la méthode isRunning(). Un autre avantage apparaît lors du débogage. En effet, si au runtime un des objets est à null, vous aurez un null pointer exception avec le numéro de ligne. Mais qu’est-ce qui est null? L’objet ‘Auto’, ‘Motor’ ou ‘State’? Ces exemples démontrent que de ne pas respecter la loi de Demeter n’est pas vraiment grave au premier abord. Cependant, en la respectant, non seulement votre code sera plus clair, mais vous gagnerez également beaucoup de temps sur la maintenance ou le débogage. Et, comme vous le savez, le temps c’est de l’argent!

gabriel bélanger

Billet précédent

Jurgen Appelo à Montréal pour nous présenter la gestion du changement Agile

Billet suivant

Codapalooza 2e édition