Principes SOLID en PHP : guide complet avec exemples de code

Introduction : pourquoi SOLID est la base d'un code PHP de qualité

Chaque développeur PHP rencontre tôt ou tard le problème du « code spaghetti » : des classes surchargées, des modifications qui cassent toute l'application à un seul endroit, et des tests qui deviennent un cauchemar. La solution à ce problème réside dans les principes SOLID. Développés par Robert Martin (Oncle Bob), ces cinq principes de programmation orientée objet aident à créer un code flexible, maintenable et évolutif.

Dans cet article, nous allons décortiquer chacun des cinq principes SOLID avec des exemples pratiques en PHP. Vous apprendrez à les appliquer dans des projets réels et verrez la différence entre le « mauvais » et le « bon » code. Ce contenu convient aussi bien aux débutants qu'aux développeurs expérimentés souhaitant structurer leurs connaissances.

1. Single Responsibility Principle (SRP) — principe de responsabilité unique

Essence du principe

Une classe ne doit avoir qu'une seule raison de changer. Cela signifie que chaque module ou classe est responsable d'une tâche spécifique unique.

Mauvais exemple (violation du SRP)

<?php\nclass Report {\n    public function generateReport($data) {\n        // Génération des données du rapport\n        $report = "Rapport : " . json_encode($data);\n\n        // Sauvegarde dans un fichier\n        file_put_contents('report.txt', $report);\n\n        // Envoi par email\n        mail('admin@example.com', 'Nouveau rapport', $report);\n\n        return $report;\n    }\n}\n?>

Ici, la classe Report fait trois choses différentes : générer le rapport, le sauvegarder et l'envoyer. Modifier la logique d'envoi d'email cassera la génération du rapport.

Bon exemple (respect du SRP)

<?php\nclass ReportGenerator {\n    public function generate(array $data): string {\n        return "Rapport : " . json_encode($data);\n    }\n}\n\nclass ReportSaver {\n    public function save(string $report, string $filename): void {\n        file_put_contents($filename, $report);\n    }\n}\n\nclass ReportMailer {\n    public function send(string $report, string $email): void {\n        mail($email, 'Nouveau rapport', $report);\n    }\n}\n\n// Utilisation\n$generator = new ReportGenerator();\n$report = $generator->generate($data);\n\n$saver = new ReportSaver();\n$saver->save($report, 'report.txt');\n\n$mailer = new ReportMailer();\n$mailer->send($report, 'admin@example.com');\n?>

Maintenant, chaque classe a une seule responsabilité, et modifier la méthode de sauvegarde n'affectera pas l'envoi d'email.

2. Open/Closed Principle (OCP) — principe d'ouverture/fermeture

Essence du principe

Les entités logicielles doivent être ouvertes à l'extension, mais fermées à la modification. En d'autres termes, vous devez pouvoir ajouter de nouvelles fonctionnalités sans modifier le code existant.

Mauvais exemple (violation de l'OCP)

<?php\nclass PaymentProcessor {\n    public function process($type, $amount) {\n        if ($type === 'credit_card') {\n            // Traitement de la carte de crédit\n        } elseif ($type === 'paypal') {\n            // Traitement PayPal\n        } elseif ($type === 'bitcoin') {\n            // Traitement Bitcoin\n        }\n        // Chaque nouveau type de paiement nécessite une modification de cette méthode !\n    }\n}\n?>

Bon exemple (respect de l'OCP)

<?php\ninterface PaymentMethod {\n    public function process(float $amount): bool;\n}\n\nclass CreditCardPayment implements PaymentMethod {\n    public function process(float $amount): bool {\n        // Logique de paiement par carte de crédit\n        echo "Paiement par carte : $amount\\n";\n        return true;\n    }\n}\n\nclass PayPalPayment implements PaymentMethod {\n    public function process(float $amount): bool {\n        // Logique de paiement via PayPal\n        echo "Paiement PayPal : $amount\\n";\n        return true;\n    }\n}\n\nclass BitcoinPayment implements PaymentMethod {\n    public function process(float $amount): b