Множествено наследяване на QObject поради достъпа до метода deleteLater().

Наистина се нуждая от този метод deleteLater(), тъй като не мога да използвам „изтрий това“ в кода на IObserver - това ще извика деструктора на IObserver, а не класовете MainForm или Storage например.

Ако направите своя деструктор виртуален (и трябва!), той ще извика извлечения деструктор съвсем добре. Но проблемът е, че унищожаването на обект, докато той обработва някакъв сигнал/слот, може да причини проблеми с цикъла на събитията. Така или иначе ще трябва да сте много внимателни с delete this.

Проблемът е, че вече наследих QObject (индиректно) в някои класове Observer.

Един от начините, по които можете да приложите това, не съм сигурен дали е най-добрата мисъл:

template <typename Derived>
class IObserver
{

    // Just to be sure: (C++11)
    static_assert(is_base_of<Derived, QObject>::value,
                  "must inherit from QObject when using IObserver");

    void deleteMe()
    {
        QObject* thisObject = dynamic_cast<QObject*>(this);
        // no need for check if thisObject equals null. static assert does this.
        thisObject->deleteLater();
    }

};

class MainForm : public IObserver<MainForm>, public QMainWindow
{
    // ...
};

Вярвам, че този модел се нарича статичен полиморфизъм.

Изоставяне на наследяването на QObject за IObserver. Вместо това добавете такъв метод към интерфейса.

class IObserver : public QObject {
public:
   QObject *object() const = 0;
...

След това, ако изпълнението на интерфейса наследи QObject, ще върнете this указател от object() метод. Ако изпълнението на интерфейса не наследява QObject, можете просто да върнете указател към някакъв прост QObject, който ще се справи с унищожаването на този обект. След това можете просто да свържете deleteLater за обект, върнат от този метод.

Извън темата
Използването на интерфейси за наблюдение в Qt обикновено е остаряло, слотовете и сигналите вършат тази работа перфектно и това е по-гъвкав подход.