1

私は余暇にかなり大きなプラグイン駆動のアプリを構築していますが、ショーストップの設計上の欠陥に遭遇しました。私のアプリはポリシー/特性ベースの設計を使用していますが、Qt を使用しているため、(テンプレートと MI ではなく) MI のみを使用して実行されます。これらのクラスには、純粋な仮想クラスもあれば、エンド ユーザーが触れてはならない内部でかなり重要な機能を実行するものもあります。

私の問題は、これらのクラスの一部がシグナル/スロットを必要とするため、QObject から派生することです。問題なく、仮想的に継承することができます。しかし、私が抱えている問題は、Qt クラスから派生させ、それを 1 つ以上の特性で拡張したい場合です。

class Sy_abstractGLViewport : public QGLWidget, public Sy_saveable, public Sy_abstractObject
{
    ...
}

ここで QGLWidget は QObject から派生していますが、事実上ではなく、あいまいさの問題を引き起こしています。

Sy_saveableたとえば、純粋な仮想を作成し、Sy_saveable_impそこから実際の実装を含む を派生させる Bridge パターンを検討しました。次に、それSy_abstractGLViewportを集約経由で使用します。

アプリはプラグインベースであるため、これはかなり専門的ではないように思えます。将来のプラグイン作成者がすべてのインターフェースメソッドを集約されたインスタンスに「接続」するのは少し残念です。エンドユーザーがメソッドをオーバーライドしたい場合があるため、マクロを使用して自動化することさえできません。

この問題を解決するパターンはありますか? または、MI を必要としないが、同じ柔軟性を提供するパターンですか? これは私の個人的な趣味のプロジェクトです。多くのリファクタリングを行ってもかまいません。正しくやりたいと思っています。

4

1 に答える 1

1

QObject を継承する複数のクラスから継承することはできません。

継承の代わりに構成を使用してみてください。継承より合成を参照してください。

Q3Signalクラスを使用することもできます。QT doc によると、古いQT3に属していますが：

Q3Signal クラスを使用して、QObject を継承しないクラスのシグナルを送信できます。

于 2011-07-27T11:18:30.157 に答える