c++ - 如果包含的对象也继承，如何定义相互继承的容器？ (以 QObject 为基础)

Question

背景:

• 我的类(class)名为 ObjectListModel继承QAbstractListModel并包含 QObjectList .对象是行，它们的属性是列(使用 QMetaObject 设置)，通知更改会传播到 View 。还有一些容器助手(开始/结束/迭代器/大小)，以便我可以迭代存储的 QObject。
• 我还有一个 TypedObjectListModel<T> ，它提供了类型安全(主要是通过覆盖 push_back 等并定义新的 iterator 类型来执行 static_cast 到 T)。

当我只有一种类型的对象时，这一切都非常有效。我只是创建新类(例如 FruitsModel，其中包含 Q_OBJECT，并继承 TypedObjectListModel<Fruit>。这只能包含 Fruits 或 Fruit-subobjects。

但是，我现在有一个可以在两种不同状态下运行的应用程序。在第二种状态下，模型应该只包含 Apples，而不是 Bananas(或者 Fruits，这是一个具体的基类)。

所以，我想创建一个 ApplesModel类型，应该继承 FruitsModel并且只需更改 T 的类型。这让我遇到了麻烦，因为我得到了继承钻石OF DEATH:

 QObject
       |
 QAbstractListModel
       |
 ObjectListModel -------------------
       |                           |
 TypedObjectListModel<Fruit>     TypedObjectListModel<Apple>
       |                           |
 FruitsModel  -------------------ApplesModel

这在概念上也是错误的，因为 FruitsModel::push_back(Fruit*) 在 ApplesModel 中是非法的。但是，应该可以读取/迭代 Fruits(而不仅仅是 Apples)。

此外，我在 FruitsModel ( findFruitById) 中有一些函数应该被覆盖，并且只在 ApplesModel 中返​​回苹果。

用 C++ 解决这个问题的首选设计模式是什么？

我怀疑(希望)我不是第一个尝试做类似事情的人。

我尝试了很多想法，但我陷入了各种死胡同。您可能认为 ObjectListModel 的虚拟继承可以解决问题，但后来我使用 QObject::findChild 得到了这个:

error C2635: cannot convert a 'QObject*' to a 'ApplesModel*'; conversion from a virtual base class is implied

上述问题可以通过我自己的 findChild 实现来补救，改用 dynamic_cast，但仍然存在一些死胡同。

template<typename T>
inline T myFindChild(const QObject *parent, const QString &name = QString())
{ 
    return dynamic_cast<T>(qt_qFindChild_helper(parent, name, reinterpret_cast<T>(0)->staticMetaObject)); 
}

更新

geekp 有以下建议:

Inherit Apple from Fruit and don't bother with ApplesModel

然后我如何强制 FruitsModel 中只有苹果？还有，我每次我拿苹果(作为水果)时都需要垂头丧气。

Don't inherit from FruitsModel (why would you if you are not using it's methods?)

我正在使用一些方法，尤其是阅读方法。

Don't inherit from TypesObjectListModel of Apple and subclass only FruitsModel.

与不用 AppleModel 一样的缺点。

Answer 1

所以读写操作在继承方面是根本不同的。

回到 OOP 101，还记得关于正方形和长方形的寓言吗？人们常说正方形是长方形的一种，但只有在阅读时才会如此。

写作时，正方形不是长方形的一种，长方形是正方形的一种!

即:

bool test( Rectangle* r ) {
  int old_height = r->GetHeight();
  int old_width = r->GetWidth();
  r->SetWidth(old_width+100);
  return old_height == r->GetHeight();
}

上述函数对所有“真实”矩形返回 true，但对于 Squares 可能不会。因此，对于 Rectangle 合理的 SetWidth 契约对于 Square 是违反的。

另一方面，Rectangle 的每个只读接口(interface)都由 Square 完美处理。

这可能会给你带来这样的困惑:

struct IRectangleRead { ... };
struct ISquareRead { ... };

struct ISquareWrite: virtual ISquareRead { ... };
struct IRectangleWrite:ISquareWrite, virtual IRectangleRead { ... };

struct ConstRectangle: virtual IRectangleRead { ... };
struct ConstSquare: virtual ISquareRead, virtual IRectangleRead { ... };

struct Rectangle: ConstRectangle, IRectangleWrite { ... };
struct Square: ConstSquare, ISquareWrite { ... };

这会产生一团糟的继承层次结构，但是可以在每个方法上放置限制性契约，并且实现该方法的每个对象都将遵守它们。

现在，您应该注意到，如果您的对象是不可变的，上述操作会变得非常容易。那么唯一的写作形式就是通过工厂函数，事情变得整洁。

所以这里的具体教训是——拆分代码的读取部分和修改部分。公共(public)修改部分(作用于基类)未公开，因为该操作在子类情况下无效。

普通阅读部分是公开的，子类型阅读部分也是。

子类型编写代码转发给私有(private)公共(public)基类编写代码。