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.
Suite de https://lorenzofox.dev/posts/lets-build-a-framework-part-1 l'auteur simplifie le composant / framework qu'il avait créé. Il plaide en faveur de l'utilisation de solutions maisons pour lutter contre l'augmentation de la taille des frameworks JS
Suite de https://lorenzofox.dev/posts/component-as-infinite-loop/ l'auteur montre comment construire un composant par composition, dont le fonctionnement est similaire à un composant VueJS
Un tutoriel avec utilisation du typage générique en PHP
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.
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...
Ça concerne Vue 3
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre (mais ça marche pour autre chose que la musique)