L’article critique l’usage des entités Doctrine dans Symfony, notamment leur double rôle de modèle de données et de formulaire, qui crée des incohérences entre les contraintes PHP, les validateurs et la base de données. Par exemple, une propriété marquée comme obligatoire (#[Assert\NotBlank], colonne SQL non nullable) peut être définie comme optionnelle en PHP (?string $name = null), permettant la création d’objets invalides qui ne seront rejetés qu’au moment du flush(). Cette approche fragilise la cohérence du code, notamment en violant les principes SOLID et DDD, et retarde la détection des erreurs.
L’auteur illustre ce problème par un cas concret où une commande d’import en production échoue à cause d’un champ vide dans un fichier CSV, alors que les tests et PHPStan passaient. Le code PHP autorise temporairement des données incomplètes (pour les formulaires), mais la base de données impose des contraintes strictes, révélant une contradiction entre les couches applicatives. Cette dualité entraîne des invariants non protégés, un modèle anémique et des vérifications redondantes de null dans le code métier.
Pour résoudre ces problèmes, l’article suggère de séparer clairement les responsabilités : utiliser des entités Doctrine strictes pour la persistance et des DTO (Data Transfer Objects) pour les interactions avec les formulaires. Cela permet de garantir la validité des données dès leur création et d’éviter les incohérences entre les types PHP, les validateurs et le schéma de la base de données.
L'article explique le Decorator Pattern en PHP, une solution élégante pour ajouter des comportements à un objet sans modifier son code existant. L'auteur illustre les problèmes des classes "Dieu" (trop de responsabilités) et de l'héritage multiple avec des exemples concrets comme un système de logging. Le pattern permet de wrappper dynamiquement un objet (ex: FileLogger) dans des décorateurs (ex: DatabaseLogger, SlackLogger) pour étendre ses fonctionnalités, tout en gardant le code modulaire, testable et ouvert à l'extension. Une alternative propre aux cascades de sous-classes et aux couplages forts.
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