C'est un classique des discussions à la machine à café entre développeurs. Un collègue dev Python vous regarde avec condescendance et lâche : "Mais attends, en PHP, une classe ne peut étendre qu'une seule classe parente ? C'est super limité non ?"
La réponse courte : Non. C'est une excellente chose. Voyons pourquoi.
Le problème du diamant (Deadly Diamond of Death)
Imaginons que PHP autorise l'héritage multiple. Vous avez une classe Robot et une classe Animal qui ont toutes les deux une méthode manger() (le robot consomme de l'électricité, l'animal de la nourriture).
Vous créez une classe Cyborg extends Robot, Animal. Si vous appelez $cyborg->manger()... quelle méthode est exécutée ? Celle du Robot ou de l'Animal ? C'est ce qu'on appelle le problème du diamant. Ça rend le code imprévisible et difficile à débugger.
La "Composition over Inheritance"
Limiter l'héritage simple force les développeurs (et c'est particulièrement vrai dans l'écosystème Symfony) à utiliser la composition. Au lieu de dire "Mon objet EST un X et un Y", on dit "Mon objet A un X et un Y".
On injecte nos dépendances via le constructeur. C'est la base de l'injection de dépendances de Symfony, et c'est ce qui rend notre code testable (via les mocks).
Les alternatives natives en PHP
PHP n'est pas bête pour autant et propose des outils élégants pour contourner les vraies limites :
- Les Interfaces : Une classe peut implémenter une infinité d'interfaces. Cela permet de définir des "contrats" (ex:
implements LoggerInterface, EventSubscriberInterface). - Les Traits : Si vous avez vraiment besoin de partager du code métier pur (des méthodes concrètes) entre des classes qui n'ont rien à voir, les Traits sont là pour ça. Symfony les utilise massivement (ex:
TimestampableTrait).
En résumé : le manque d'héritage multiple en PHP n'est pas un défaut de conception. C'est une protection contre le "code spaghetti" fortement couplé.
