L'article aborde une troisième stratégie d'héritage dans Doctrine, souvent négligée au profit des approches binaires STI (Single Table Inheritance) et CTI (Class Table Inheritance). L'auteur propose la Mapped Superclass, une solution intermédiaire qui permet de partager des propriétés et méthodes entre classes PHP sans imposer de contrainte de stockage unique ou de jointures coûteuses. Contrairement à STI (une table commune avec un discriminant) ou CTI (tables séparées liées par clé primaire), cette méthode crée des entités autonomes tout en conservant une structure de code cohérente.
L'auteur illustre son propos avec un cas concret : une classe abstraite AbstractContent marquée comme #[ORM\MappedSuperclass], héritée par des entités comme Post, Page ou Category. Chaque enfant bénéficie des propriétés communes (titre, slug, statut, métadonnées SEO) sans partager une table physique, évitant ainsi les inconvénients des deux autres méthodes. STI aurait entraîné des colonnes inutiles ou nulles, tandis que CTI aurait alourdi les requêtes avec des jointures systématiques.
Enfin, l'article souligne que cette approche offre un équilibre entre modularité et performance, en s'affranchissant des compromis des stratégies classiques. La Mapped Superclass est présentée comme une solution pragmatique pour des hiérarchies de modèles complexes, où la réutilisation du code prime sur les contraintes de persistance.
Ce billet explore l'origine et la signification de l'adage "favoriser la composition à l'héritage" en programmation orientée objet. Cette phrase, popularisée par le livre "Design Patterns" (Gang of Four), oppose l'héritage (réutilisation en "boîte blanche") à la composition (réutilisation en "boîte noire"). L'auteur analyse les avantages et limites de chaque approche, soulignant que la composition offre plus de flexibilité à l'exécution mais peut nécessiter plus de travail. Il rappelle aussi le contexte historique et linguistique de ce débat, ainsi que l'influence des travaux de Barbara Liskov sur la sémantique des sous-types.
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.
Cet article fait partie de ceux mentionnés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique que la réutilisation de code par héritage est un code smell et il montre comment le corriger
Un article passionnant sur l'héritage vs la composition en POO. J'en retiens sa conclusion : il ne sert à rien de se forcer à utiliser des grands principes (DRY, héritage, composition, etc.) tant que l'on n'a pas une compréhension claire du problème que l'on essaye de résoudre... par contre, ces grands principes sont très utiles pour le refactoring.
Des réflexions très intéressantes sur la pérennisation de notre vie numérique après la mort... et je cite l'auteur pour définir le dead-man switch "Un dead-man switch est une procédure exécutée à la mort d’une personne. "
Tout est dans le titre
Tout est dans le titre
Il s'agit de l'encapsulation, de la composition, de l'héritage, des interfaces et des méthodes statiques...
Tout est dans le titre, sauf que ça concerne PHP
Tout est dans le titre
Tout est dans le titre
L'auteur explique comment fonctionne l'héritage en JavaScript (et tape sur IE au passage, mais c'est mérité)
Tout est dans le titre