【发布时间】:2013-04-03 22:17:14
【问题描述】:
我想知道以下案例,但我似乎缺少足够的术语来在任何地方找到任何答案。
让我们从一个常见的案例开始:我总共有 3 个班级。其中 2 个继承自第 3 个,被视为专业化。
现在这 3 个类仍然是部分抽象的,并且每个都引入了新的纯虚函数,因为这种“类结构”可以根据不同的目的以不同的方式实现。并且这三个类中的每一个都是从内部访问纯虚函数,因此它们不能在以后实现。
然后是第 4 类,它继承自第 2 类,以便专门化第 2 类的纯虚函数的用途。还有第 5 类,对第 3 类也是如此。
现在还有第一类的纯虚函数,需要根据第四类和第五类进行专门化。这就是我遇到一些问题的地方,我可以想出 2 种方法来解决这个问题,但这并不能真正让我满意。
- 让第 6 类继承自第 1 类,并专门针对第 4 类和第 5 类的需求,并让这些类从第 6 类继承。这将导致“可怕的钻石”。
- 有一个不继承自 1 类的第 6 类,但它实现了适合第 4 类和第 5 类的专用目的。然后让第 4 类和第 5 类从第 6 类继承,并添加第 1 类的纯虚函数的实现。这些实现除了调用 6th 的类似函数,同时传递相同的参数等之外,什么也不做。
我目前倾向于第二种解决方案,因为我想避免“钻石恐惧”。但我不喜欢它附带的额外实现代码。难道没有更简单的方法来组合不同的(接口/)类吗?
例如,使用第二种解决方案,我在考虑类似在第 6 类中具有与在第 1 类中声明的相同函数原型,而不是告诉编译器第 1 类的函数应该被第六课。遗憾的是,第 4 和第 5 类的类声明中的 using myfunction; 不起作用。
或者一般问:有没有办法加入“接口”——这意味着一个类的纯虚函数可以由一个完全不同的类定义,只要原型相同并且只要他们都是从孩子那里继承来的。我想尽可能避免重复代码,因为我不想要“繁重”的类。
如果这个照明太抽象,我会举个例子。
€dit:征求您的意见:在这种情况下,最好的解决方案是什么?
【问题讨论】:
-
简短的回答是“不”,您不能“外包”覆盖。
标签: c++ inheritance virtual