Imaginez une classe qui envoie des e-mails : si elle crée elle-même son client SMTP dans son constructeur, impossible de la tester sans réellement envoyer de mails, ni de changer de fournisseur sans modifier son code. L’injection de dépendances consiste à lui « fournir » ce client depuis l’extérieur, généralement via le constructeur, plutôt que de le fabriquer en dur.
Fonctionnement en PHP
On type le paramètre du constructeur avec une interface plutôt qu’une classe concrète, ce qui permet d’en changer l’implémentation sans toucher au code qui l’utilise : public function __construct(private LoggerInterface $logger) {}. Des bibliothèques comme celles de Symfony ou de PHP-DI automatisent cette fourniture via un « conteneur » qui résout les dépendances à la volée.
Dans WordPress
Le cœur de WordPress, très procédural, ne pratique pas nativement l’injection de dépendances : les fonctions vont chercher directement les globales ($wpdb, $post). Les extensions ambitieuses et les frameworks orientés objet construits sur WordPress introduisent souvent un conteneur léger pour organiser leurs classes de service, ce qui facilite grandement les tests unitaires.
Exemple
interface Notifieur {
public function envoyer(string $message): void;
}
class ServiceCommande {
public function __construct(private Notifieur $notifieur) {}
public function confirmer(): void {
$this->notifieur->envoyer('Commande confirmée');
}
}
À ne pas confondre avec
L’injection de dépendances n’est pas la même chose qu’un simple import ou un require : elle porte sur la relation entre objets, pas sur le chargement de fichiers. Elle se distingue aussi du service locator, où l’objet va lui-même chercher ses dépendances dans un registre global, une pratique plus proche de ce que fait le cœur de WordPress.