Loi de Demeter en PHP : écrire un code qui parle moins… mais mieux

Dans le développement logiciel, on entend souvent parler de bonnes pratiques : découplage, séparation des responsabilités, principes SOLID… Mais il en existe une, parfois oubliée, qui mérite toute notre attention : la loi de Demeter. Aussi appelée “principe du moindre savoir”, elle aide à écrire un code plus robuste, lisible et maintenable.

---

Qu’est-ce que la loi de Demeter ?

Formulée à la fin des années 80 au MIT, la loi de Demeter repose sur une idée simple :

“Un objet ne doit parler qu’à ses amis proches, pas aux amis de ses amis.”

En d’autres termes, une classe doit limiter sa connaissance du système. Elle ne devrait interagir qu’avec :

• elle-même (ses propres méthodes),
• ses attributs directs,
• ses paramètres de méthode,
• les objets qu’elle crée,
• et éventuellement des objets globaux (comme des singletons, mais c’est à éviter).

L’objectif est d’éviter un code trop dépendant de la structure interne d’autres objets.

---

Exemple de violation de la loi de Demeter

Prenons un exemple classique :

$city = $order->getCustomer()->getAddress()->getCity();

Ici, pour obtenir la ville d’un client, l’objet Order doit exposer son Customer, qui expose son Address, qui expose sa City.

On voit apparaître ce qu’on appelle le train wreck pattern : un long chaînage d’appels qui montre que l’on connaît beaucoup trop la structure interne de l’objet.

Exemple corrigé

Une meilleure approche consiste à déléguer la responsabilité aux objets concernés :

class Order
{
    private Customer $customer;

    public function getCustomerCity(): string
    {
        return $this->customer->getCity();
    }
}

Puis côté utilisation :

$city = $order->getCustomerCity();

Ainsi, l’objet Order devient responsable de la façon dont on accède à l’information.
Si demain la structure interne du Customer change (par exemple si l’adresse n’est plus directement liée à l’objet Customer), le code appelant ne sera pas impacté.

Les avantages concrets

Respecter la loi de Demeter apporte plusieurs bénéfices immédiats :

• Robustesse : un changement interne n’impacte pas le code appelant.
• Encapsulation : les objets cachent leurs détails internes.
• Lisibilité : moins de chaînages, un code qui exprime directement ce qu’on veut obtenir.
• Testabilité : il est plus facile de tester une méthode simple que de simuler un long parcours d’objets.

---

Conclusion

La loi de Demeter est une règle simple mais puissante : “ne parlez qu’à vos amis proches”.
En évitant les appels chaînés excessifs et en déléguant les responsabilités aux bons objets, vous obtenez un code :

• plus clair,
• plus robuste,
• et plus facile à maintenir.

Prenez un moment pour relire votre code : combien de -> successifs y trouvez-vous ?
C’est peut-être le signe qu’il est temps d’appliquer la loi de Demeter.

Et vous ?

Connaissiez-vous les traits en PHP ? Partagez vos retours ou astuces en me rejoignant sur LinkedIn — je serai ravi d’en discuter !