L’auteur explique que les traits en PHP, bien que pratiques pour réutiliser du code, introduisent des problèmes majeurs : lisibilité réduite (comportement non évident), couplage caché (dépendance implicite aux propriétés protégées), encapsulation brisée et tests difficiles. Plutôt que de recourir aux traits, il recommande la composition, l’injection de dépendances ou des classes dédiées pour des architectures plus propres et maintenables. Un exemple concret montre comment remplacer un trait par une classe explicite (UserNotifier) pour clarifier les responsabilités. Une lecture utile pour éviter les pièges des traits au profit de bonnes pratiques SOLID.
L'auteur explique pourquoi le pattern Singleton, bien que séduisant par sa simplicité, se transforme souvent en antipattern coûteux. À travers son expérience sur un projet legacy truffé de Singletons, il montre comment ce pattern crée des dépendances cachées, rend les tests impossibles et engendre des problèmes de concurrence. Le Singleton, en agissant comme une variable globale déguisée, viole plusieurs principes SOLID (Dependency Inversion, Single Responsibility, Open/Closed) et complique la maintenance du code. Les tests deviennent difficiles à écrire et à isoler, tandis que la gestion de l’état global partagé introduit des bugs aléatoires et des goulots d’étranglement. L’auteur propose des alternatives comme l’injection de dépendances, la composition root ou les factories, qui rendent le code plus testable, flexible et maintenable. Il conclut que le Singleton doit être évité dans la plupart des cas, sauf pour des ressources vraiment uniques et globales, et insiste sur l’importance de bien évaluer les compromis avant de l’utiliser.
L'article explore comment appliquer les principes SOLID dans le cadre du développement avec Symfony. Voici un aperçu des points clés abordés :
-
Single Responsibility Principle (SRP) : L'article explique comment structurer les classes dans Symfony pour qu'elles aient une seule responsabilité, facilitant ainsi la maintenance et les tests.
-
Open/Closed Principle (OCP) : Il montre comment concevoir des composants Symfony qui sont ouverts à l'extension mais fermés à la modification, en utilisant des techniques comme l'héritage et les interfaces.
-
Liskov Substitution Principle (LSP) : L'article discute de l'importance de s'assurer que les objets des sous-classes peuvent remplacer ceux des classes de base sans affecter le comportement du programme, un concept crucial pour la réutilisabilité du code.
-
Interface Segregation Principle (ISP) : Il met en avant l'avantage d'utiliser plusieurs interfaces spécifiques plutôt qu'une seule interface générale, permettant aux classes de n'implémenter que les méthodes nécessaires.
-
Dependency Inversion Principle (DIP) : L'article souligne l'importance de dépendre des abstractions plutôt que des implémentations concrètes, en utilisant l'injection de dépendances et les interfaces pour rendre le code plus flexible et réutilisable.
En appliquant ces principes, les développeurs peuvent créer des applications Symfony plus robustes, maintenables et évolutives. L'article fournit des exemples pratiques et des conseils pour intégrer ces principes dans les projets Symfony.
L'abstraction, souvent perçue comme un concept réservé aux architectes, est en réalité essentielle pour tous les développeurs PHP grâce aux interfaces. Ces dernières permettent de créer un code plus propre, modulaire et flexible en définissant des méthodes sans se soucier des détails d'implémentation sous-jacents. Les interfaces agissent comme des contrats, garantissant que les classes qui les implémentent suivent une structure spécifique, ce qui réduit le couplage et augmente la flexibilité. Elles facilitent également les tests unitaires en permettant de simuler des implémentations et soutiennent les principes SOLID, essentiels pour un code maintenable et évolutif. En adoptant les interfaces, les développeurs PHP peuvent améliorer la modularité, la réutilisabilité et la maintenabilité de leur code.
Tout est dans le titre
Tout est dans le titre
Le résumé de 3 conférences
- Les classes abstraites c’est fini (et c’est la faute à TDD)
- 🧑🎤🎸 La preuve de programme vous fera apprécier les tests
- (Re)devenez pote avec le CSS.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Il s'agit de l'article à propos du "D" de SOLID :-)
Une série d'articles sur SOLID -> ici l'auteur parle du "S", ou principe de responsabilité unique
Uncle Bob rappelle pourquoi les principes SOLID sont toujours d'actualité, même pour les architectures micro services