Confus à propos de l'héritage et d'une utilisation correcte. Devrais-je éviter d'utiliser des membres dans la classe de base?
J'utilise C++, mais aussi loin que je comprenne la plupart OO Principes sont la langue croisée.
Dans la plupart des articles que j'ai lus et aimé l'héritage, les conseils sont à propos de:
- ne pas l'utiliser dans le but de la réutilisation du code.
- interface hériter non des implémentations.
- utilisez "Interfaces" (classe abstraite pure) comme classe de base.
- préfère la composition sur l'héritage, ainsi que sur des articles connus sur l'abus d'héritage.
- préfère travailler avec des interfaces pour la qualification.
Exemples:
Meyers efficace C++: Point 20: Évitez les membres de données dans l'interface publique.
Essayer d'améliorer mon OO Capacités et compréhension Je lisons ce livre: Head première analyse et conception orientée objet et vu cette utilisation dans de nombreux autres exemples de vie réels, où Ils mettent tous les attributs de classe dérivés communs dans les classes de base.
Dans le livre, il existe un exemple de classes de guitare et de mandoline, où la classe de base a tous les membres courants et la classe dérivée n'a que les données uniques.
J'ai vu ces motifs dans de nombreux autres exemples et dans le travail de la vie réelle.
La question concerne le conflit entre ces deux choses, toutes les directives que j'ai énoncées et contredire des exemples de la vie réelle (ou comme des exemples de ce livre):
Peut-être que les interfaces publiques ont des "règles" plus strictes de classes intérieures régulières?
Ou peut-être que ces exemples sont mauvais et que je devrais continuer à utiliser l'héritage uniquement pour les interfaces (classes abstraites sans membres)?
Je sais que ce sont toutes des recommandations et non des lois de l'État, mais je pense que je manque quelque chose dans ma compréhension.
EDIT: La question est sur la phase de conception, pas le gâchis en cours d'évolution ... Si j'essaie de concevoir de nouvelles classes et de noter les mêmes membres entre deux classes avec les mêmes interfaces, dois-je les mettre dans la classe de base?
EDIT: Ajout de l'exemple du livre qui m'a confondu, pourquoi hériter des membres?
EDIT: Cette directive principale montre le problème que j'ai discuté et essaie de le résoudre, mais je pense que la solution est trop complexe.
"... Par exemple, le centre doit être mis en œuvre par chaque classe dérivée de la forme ... Comment pouvons-nous bénéficier des hiérarchies stables des hiérarchies de mise en œuvre et l'avantage de la réutilisation de la mise en œuvre du héritage de la mise en œuvre"
Si j'essaie de concevoir de nouvelles classes et de remarquer les mêmes membres entre deux classes avec les mêmes interfaces, devrais-je les mettre dans la classe de base?
Non pas tout de suite. Par exemple dans les CQR, les commandes et les événements partagent beaucoup la même structure. Il pourrait y avoir des commandes portant les mêmes données que l'événement résultant. Ou même entre les commandes et les événements totalement indépendants l'un à l'autre. Et bien sûr, les commandes et les événements auront les mêmes getters. Deux classes ou plus tiennent presque ou les mêmes membres ne les transforment pas conceptuellement dans la même chose.
Pourquoi InstrumentSpec ne contient pas numStrings malgré les deux instruments a des chaînes. Parce que conceptuellement, tous les instruments n'ont pas de chaînes. Initialement, il vous suffit de fonctionner avec InstrumentSpec. Ce dernier trouvez que vous trouvez des raisons de faire InstrumentSpec comportement de manière différente, vous ajoutez GuitarSpec et MandolineSpec. Plus tard, vous réalisez que votre code est souvent jailli sur GuitarSpec car il doit donc être traité de manière à plus de moyens que des spécifications d'instruments. Plus tard, ce n'est pas seulement GuitarSpec Vous avez plus de classes qui ont également des chaînes et que vous vous posez tous pour traiter'em comme vous l'avez fait avec GuitarSpec... plus tard, vous réalisez que tous ces Les cours dérivés sont traités de la même manière parce qu'ils sont tous un nouveau concept StringedInstrumentSpec. Une nouvelle abstraction qui dérive de InstrumentSpec et une nouvelle sous -hierarchie de la marque de classes qui, malgré les différences, elles sont toutes des spécifications immobiles.
Par héritage, vous pouvez exprimer des degrés de concrétiquence. Concreté que vous ne voulez pas que d'autres composants soient au courant. Les détails des classes dérivées sont connus par très peu de composants. Composants qui
- fonctionner au même niveau d'abstraction
- sera étroitement couplé aux classes dérivées qu'ils travaillent avec. Mais ce couplage est attendu et, si au bon endroit, inoffensif.
Ce concret est également un mécanisme d'expansion. L'expansion signifie, fournissez le concept d'origine avec plus de fonctionnalités ou laissez-le faire ce qu'il fait, mais de différentes manières.
pourquoi hériter des membres?
Si les membres sont intrinsèques sur le concept modélisé par la classe abstraite, le concept ne peut pas exister sans ces membres. Eh bien, ce n'est pas totalement vrai. Ils peuvent mais au détriment de la complexité (par exemple l'exemple Shape)