Considérez le code suivant:
Struct Base
{
int x;
double y;
}
Struct A : public Base
{
}
Struct B : public Base
{ //here I don't want x (Base::x) to be inherited.
// is there a way to delete it (something like delete Base::x)
}
Struct C : public Base
{
}
3 Réponses :
L'héritage public rend une relation est-a . Cela signifie B . Et cela signifie si base a x puis puisque b x . Vous devez repenser cette conception si vous avez ce problème. Envisagez de commuter la relation entre B et base à composition:
Considérez une classe de base RestaurantBase qui a entre autres membres un membre m_teaspoon . Toutes les classes de restaurant ( struct Italiafood {} , struct françaisfood {} , etc.) hériter de RestaurantBase . Maintenant, il y a du restaurant japonais ( struct Japanfood {} ), qui est aussi un restaurant mais n'a pas de cuillère à café. Donc, pour cela, je ne veux pas m_teaspoon à hériter. Mais c'est un restaurant et devrait hériter des 100 autres membres de RestaurantBase
@Gaetan a lu Scott Meyors efficace C ++ - Point 34. Différencie entre héritage de l'interface et héritage de la mise en œuvre. En prenant cuillère à thé dans votre interface, vous forcez ce détail de mise en œuvre sur les enfants de votre classe de base. Envisagez de faire des ustensiles et une partie abstraite de l'interface.
Il n'y a aucun moyen de "supprimer" les membres hérités des données héritées et vous ne pouvez même pas les cacher. Ils ont une partie intrinsèque de la sous-classe.
Si B n'héritera que des parties de base , vous devez diviser base :
Merci Stephan, peut-être que C ++ 18 devrait introduire un tel Supprimer x , pour autoriser héritage partiel. Si vous envisagez l'exemple de restaurant que j'ai mentionné ci-dessus, il est assez gênant de créer une nouvelle classe de base simplement pour empêcher la héritage d'une variable de membre unique.
Les problèmes @gaetan sont, votre cas d'utilisation décrite ne respecte pas vraiment les principes de l'OPO, ce n'est donc pas probablement un cas d'utilisation que la langue s'adresse à sa mise en œuvre de l'héritage. Vous tombez fondamentalement dans The Circle-ellipse Piège , mais un peu pire: là-bas aucune raison de "nourriture" est une sorte de "restaurant".
En termes de masquage d'un membre de la classe de base, vous pouvez y parvenir en héritant en héritant à partir de celui-ci et en exposant de manière sélective les membres de la classe de base publics (ou protégés) à l'aide de en utilisant :
Si
B ne devrait pas avoirbase :: x , puisb ne doit pas hériter publiquement debase .Pourquoi
b Abase s'il ne veut pas unx ? Peut-être avez-vous un "basex " et "basey " concept de lutte pour se produire. Ou peut-être qu'ils devraient être contenus, en cas de besoin, pas hérité?BTW: Pourquoi les bowvotes?
@doctorlove Considérez une classe de base
RestaurantBase qui a entre autres membres un membrem_teaspoon . Toutes les classes de restaurant (struct Italiafood {} ,struct françaisfood {} , etc.) hériter deRestaurantBase . Maintenant, il y a du restaurant japonais (struct Japanfood {} ), qui est aussi un restaurant mais n'a pas de cuillère à café. Donc, pour cela, je ne veux pasm_teaspoon à hériter. Mais c'est un restaurant et devrait hériter des 100 autres membres deRestaurantBase@Gaetan a lu Scott Meyors efficace C ++ - Point 34. Différencie entre héritage de l'interface et héritage de la mise en œuvre. En prenant cuillère à thé dans votre interface, vous forcez ce détail de mise en œuvre sur les enfants de votre classe de base. Envisagez de faire des ustensiles et une partie abstraite de l'interface.
Si les restaurants ont des cuillères à café, quelque chose sans cuillère à café n'est pas un restaurant. Une façon différente de sculpter les choses évitera le problème. Comme @fantaticmrfox dit