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

Question

背景:

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

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

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

所以，我想创建一个 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可能不会。因此，对于矩形来说合理的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)修改部分(适用于基类)未公开公开，因为该操作在子类情况下无效。

公共(public)阅读部分是公开的，子类型阅读部分也是如此。

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