Chapitre 19. Hiérarchies
Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : translation-feedback@oreilly.com
L'un des aspects d'une classe était de servir de dépôt pour le code et les informations partagés par toutes les instances (objets) de cette classe. En termes d'efficacité, c'est une bonne idée car l'espace de stockage est minimisé et les modifications peuvent être effectuées en un seul endroit. Il est cependant très tentant d'utiliser ce fait pour justifier la création d'une hiérarchie de classes basée sur le code partagé plutôt que sur les comportements partagés... Crée toujours des hiérarchies basées sur des comportements partagés.
David West, Pensée objet
19.0 Introduction
L'héritage de classes est souvent utilisé à tort pour la réutilisation du code, pour des raisons historiques. Tu devrais préférer la composition, mais ce n'est pas si évident et cela demande plus d'expérience. La composition est dynamique et tu peux facilement la modifier, la tester, la réutiliser, etc, ce qui donne de la souplesse à tes conceptions. Dans ce chapitre, tu trouveras des recettes pour minimiser le couplage accidentel que tu ajoutes en utilisant des hiérarchies.
19.1 Rompre l'héritage profond
Problème
Tu as des hiérarchies profondes pour réutiliser le code.
Solution
Trouve le protocole et aplatis la hiérarchie en favorisant la composition plutôt que l'héritage.
Discussion
La réutilisation de sous-classification statique crée plus ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access