5.1Design patterns, architecture propre & SOLID
L'essentiel en 30 secondes
- Patterns = solutions éprouvées : des recettes d'organisation validées (Factory, Repository, injection de dépendances) + un vocabulaire commun.
- SOLID = 5 principes : responsabilité unique, ouvert/fermé, Liskov, ségrégation des interfaces, inversion des dépendances.
- Discernement : appliquer avec mesure selon le problème — ni sur-ingénierie, ni désordre.
Mini-cas filé — Riad structure sa boutique à Constantine
Riad, développeur web à Constantine, maintient une petite boutique en ligne : le code mélange requêtes SQL, HTML et règles de prix dans les mêmes fichiers, et chaque correction casse autre chose. Il centralise l'accès aux données dans un Repository, injecte ses dépendances au lieu de les créer en dur, et découpe une classe qui faisait tout. Cette section raconte sa bascule vers un code conçu pour durer — et le fil continue en 5.2, 5.3 et 5.4.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 5.2, 5.3 et 5.4.
1. Les design patterns
Au niveau expert, la question devient « comment structurer le code pour qu'il soit robuste, maintenable, évolutif ». Les design patterns (patrons de conception) sont des solutions éprouvées à des problèmes de conception récurrents : des recettes d'organisation validées par la communauté, qui évitent de réinventer la roue. Courants en PHP : la Factory (déléguer la création d'objets pour découpler), le Repository (centraliser l'accès aux données d'une entité), la Strategy (algorithmes interchangeables), l'Observer (notifier d'un événement), l'injection de dépendances (fournir à un objet ses dépendances de l'extérieur — centrale dans les frameworks modernes). Riad y retrouve ses problèmes quotidiens déjà résolus par d'autres.
Bonus décisif : les patterns donnent un vocabulaire commun — dire « c'est un Repository » communique une intention de conception. Et les frameworks (Laravel, Symfony) les utilisent massivement : les reconnaître, c'est comprendre ce que fait le framework au lieu de le subir.
2. Les principes SOLID
SOLID, ce sont cinq principes de conception orientée objet : Single Responsibility (une classe = une seule responsabilité, une seule raison de changer), Open/Closed (ouvert à l'extension, fermé à la modification : ajouter sans casser l'existant), Liskov Substitution (une classe dérivée doit pouvoir remplacer sa parente sans casser le comportement), Interface Segregation (plusieurs interfaces spécifiques plutôt qu'une grosse interface générale), Dependency Inversion (dépendre d'abstractions — interfaces — plutôt que d'implémentations concrètes). Appliqués, ils produisent un code découplé, extensible, testable. Riad commence par le S et le D : découper sa classe fourre-tout, puis dépendre d'une interface.
L'architecture propre prolonge cette réflexion : séparation des couches, découplage, code lisible. Un code qui respecte ces principes se teste facilement — et se fait évoluer sans peur.
3. Le discernement avant tout
Point de perspective essentiel : patterns et SOLID s'appliquent avec discernement, pas dogmatiquement. Le sur-ingénierie (patterns complexes et couches d'abstraction là où une solution simple suffirait) est un piège aussi réel que le sous-ingénierie (code désordonné) : complexité inutile, code plus dur à comprendre, rigidité paradoxale, temps perdu. Riad n'ajoute pas trois couches à un script d'une page — il structure ce qui grandit et dure.
Ces concepts sont en outre transversaux : ils valent dans toute programmation orientée objet, au-delà de PHP. Les maîtriser marque le passage vers l'expertise : on ne se contente plus de faire fonctionner le code, on le conçoit pour qu'il dure — une compétence qui s'acquiert par la pratique et la lecture de bon code, notamment celui des frameworks.
🔎 Exemple concret — Riad centralise l'accès aux données
Un Repository testable, dépendance injectée.
pdo->prepare('SELECT * FROM produits WHERE id = :id');
$req->execute(['id' => $id]);
$ligne = $req->fetch(PDO::FETCH_ASSOC);
return $ligne === false ? null : $ligne;
}
}
// Le contrôleur reçoit le dépôt (injection), il ne le crée pas :
// $controleur = new ProduitControleur(new ProduitRepository($pdo));Lecture : le SQL vit au même endroit, le contrôleur dépend d'une interface — on peut tester avec un faux dépôt.
Leçon : Repository + injection = code découplé, testable, qui évolue sans casse.
Vocabulaire de la section
- Design patterns
- Solutions éprouvées à des problèmes de conception récurrents, avec un vocabulaire commun.
Exemple simple : Riad centralise ses requêtes produits dans un Repository.
Ce que ce n'est pas : des règles obligatoires à appliquer partout.
Réflexe : quel problème récurrent est-ce que je résous ?
- Repository
- Pattern qui centralise l'accès aux données d'une entité en un seul endroit.
Exemple simple : Toutes les requêtes produits de Riad passent par ProduitRepository.
Ce que ce n'est pas : du SQL éparpillé dans les vues et les contrôleurs.
Réflexe : mon SQL est-il regroupé et réutilisable ?
- Injection de dépendances
- Fournir à un objet ses dépendances de l'extérieur au lieu qu'il les crée.
Exemple simple : Le contrôleur de Riad reçoit le PDO au lieu de le construire.
Ce que ce n'est pas : un new PDO caché au fond d'une méthode.
Réflexe : puis-je tester cette classe avec un faux ?
- SOLID
- Cinq principes de conception OO vers un code découplé et maintenable.
Exemple simple : Riad découpe sa classe fourre-tout (S) puis dépend d'interfaces (D).
Ce que ce n'est pas : une check-list à cocher aveuglément.
Réflexe : quelle lettre SOLID soulage ma douleur actuelle ?
- Sur-ingénierie
- Trop de structure et d'abstractions là où une solution simple suffirait.
Exemple simple : Riad laisse son script d'une page simple, sans couches.
Ce que ce n'est pas : le code désordonné sans aucune structure.
Réflexe : cette abstraction paie-t-elle son coût ?
En pratique — Concevoir un code propre et maintenable
- Découvrez quelques design patterns courants (Factory, Repository, injection de dépendances) et repérez-les dans le code d'un framework (Laravel/Symfony).
- Appliquez la Responsabilité unique (S de SOLID) : une classe = une responsabilité ; découpez une classe qui en fait trop.
- Appliquez l'Inversion des dépendances (D) : faites dépendre votre code d'une INTERFACE plutôt que d'une classe concrète (plus flexible, testable).
- Exercez le DISCERNEMENT : appliquez la structure adaptée au problème, sans sur-ingénierie (ni patterns complexes inutiles, ni désordre).
Script prêt à dire — proposer un découpage propre
« Sur notre boutique à Constantine, les requêtes SQL sont mélangées au HTML et chaque correction casse autre chose. Je propose de centraliser l'accès aux données dans un Repository et d'injecter les dépendances : on pourra tester sans la base et modifier l'affichage sans toucher aux données. Je commence par une classe, on mesure le gain, puis on étend. »
À dire en revue de code pour faire adopter un découpage progressif, sans promettre une réécriture complète.
Modèle copier-coller — grille de relecture SOLID
RELECTURE SOLID (1 classe)
S — Responsabilité unique : cette classe a-t-elle UNE seule raison de changer ? → Si non : quoi découper ? ___
O — Ouvert/Fermé : pour ajouter un cas, dois-je MODIFIER l'existant ? → Si oui : quelle extension prévoir ? ___
L — Liskov : une classe fille peut-elle remplacer sa parente ? → Test : ___
I — Interfaces : l'interface est-elle trop grosse ? → À scinder en : ___
D — Inversion : de quoi de CONCRET dépend-elle ? → Remplacer par l'interface : ___Solo / petit budget
Riad seul : appliquer S et D sur les deux classes les plus douloureuses suffit — pas besoin de tout restructurer.
TPE / équipe réduite
Un Repository partagé pour les entités critiques : toute l'équipe lit et écrit les données au même endroit.
PME à Constantine
Riad cale une relecture SOLID mensuelle avec l'équipe à Constantine : une classe passée à la grille à chaque fois.
Équipe qui démarre
Binôme : l'un code la fonctionnalité, l'autre relit avec la grille ; on n'ajoute un pattern que sur problème réel.
✓ Bonnes pratiques
- Commencer par S (responsabilité unique) et D (inversion des dépendances) : le meilleur rapport effort/gain.
- Lire du bon code (frameworks) pour voir les patterns en situation réelle.
- N'ajouter un pattern que sur un problème réel de maintenance ou de test.
✗ Pièges fréquents
- Appliquer des patterns partout « pour être pro » (sur-ingénierie).
- Abuser du Singleton (état global caché, tests difficiles) — à utiliser avec parcimonie.
- Confondre architecture et paperasse : des couches qui n'apportent rien coûtent en compréhension.
Points clés à retenir
- DESIGN PATTERNS = solutions ÉPROUVÉES à des problèmes de conception récurrents (Factory, Repository, Strategy, Observer, injection de dépendances) ; vocabulaire commun. Les frameworks les utilisent massivement.
- SOLID = 5 principes de conception OO : Single Responsibility (une responsabilité), Open/Closed (extension sans modification), Liskov, Interface Segregation, Dependency Inversion (dépendre d'ABSTRACTIONS).
- Appliqués, ils produisent un code DÉCOUPLÉ, extensible, testable, maintenable (architecture propre : couches séparées, découplage, lisibilité).
- DISCERNEMENT : appliquer avec MESURE selon le problème — le SUR-INGÉNIERIE (structure excessive) est un piège comme le désordre. Concepts TRANSVERSAUX (au-delà de PHP). Marque le passage vers l'EXPERTISE (concevoir, pas juste faire fonctionner).
Défi 48h — appliquez demain
Passez 1 classe de votre projet à la grille de relecture ci-dessus : quelle lettre SOLID vous fait le plus mal — et quel découpage proposez-vous ?
- Je peux citer 3 patterns et leur usage en une phrase chacun.
- Ma classe relue respecte S et D (ou je sais ce à découper).
- Je sais quand NE PAS ajouter de pattern.
Questions fréquentes
Faut-il apprendre les design patterns et SOLID, ou est-ce de la théorie superflue ?
Ni superflu, ni à apprendre d'un coup : ce sont des outils de conception éprouvés qui paient sur les projets qui durent. Les patterns vous évitent de réinventer (mal) des solutions validées, SOLID guide vers un code maintenable, et les deux donnent un vocabulaire commun précieux en équipe. Surtout, les frameworks utilisent ces patterns : les connaître, c'est comprendre Laravel et Symfony au lieu de les imiter. Mais ils s'apprennent progressivement (un pattern à la fois, S et D d'abord), prennent sens avec l'expérience, et s'appliquent avec discernement : un petit script n'a pas besoin d'architecture. Commencez par repérer les patterns dans du bon code, appliquez sur vos douleurs réelles — la théorie suivra la pratique.
Qu'est-ce que le sur-ingénierie, et comment trouver le juste niveau de structure ?
Le sur-ingénierie, c'est concevoir plus complexe que le problème ne l'exige : couches, interfaces et patterns là où une solution simple suffirait. Coûts réels : complexité inutile (dur à comprendre), plus de code à maintenir, rigidité paradoxale, temps perdu. Le piège classique : enthousiaste après avoir appris les patterns, on veut les appliquer partout. Pour trouver le juste niveau : partez de la douleur réelle (test impossible ? duplication ? modifications qui cassent tout ?) et choisissez l'outil minimal qui la soulage ; laissez le code simple tant qu'il ne fait pas mal ; relisez avec la grille SOLID pour vérifier, pas pour cocher. Ni cathédrale pour une cabane, ni cabane pour une cathédrale.
Que sont les design patterns et à quoi sert SOLID ?