1
4

1 に答える 1

2

いいえ、「このような」プロジェクトのデザイン パターンはありません。

デザインパターンはゴールではありません。

だから、いくつかの推測をまっすぐにしましょう:

  • 軽量のコードが必要な場合 (そうしないと、Java を使用することになります)
  • 保守可能なコードが必要です (それ以外の場合は、スパゲッティで問題ないため)
  • あなたは慣用的なコードが欲しい

これが私がすることです:

  • 個別のヘッダーでクラスを宣言する
  • 前方定義を使用してヘッダー結合を減らします
  • 対応するソース ファイルに実装を移動する
  • 不要な実装の依存関係をヘッダー ファイルから除外します。必要に応じて、ここで Pimpl イディオムを使用します。

    たとえば、ライブラリ X を使用して実装Y::frobnicateする場合はlibX.hY.h. 代わりに、Y.cppのみに含めます。

    ヘッダーで必要なクラス メンバー宣言が必要な場合libX.hは、Pimpl Idiom を使用してください。

ここで他に何が欲しいのかわかりません:)

おそらく、「インターフェース」が必要な場合は、テンプレート構成の使用を検討してください。ポリシー、戦略、状態パターン。たとえば、代わりに

    #include <set>

    struct ISensors {
        virtual int get(int id) const = 0;
        virtual int set(int id, int newval) const = 0;
        virtual std::set<int> sensors() const = 0;
    };

    class Drive {
        void update();
        Drive(ISensors &sensors);

      private:
        ISensors &sensors;
    };

あなたは考えることができます

template <typename Sensors>
class Drive {
    void update();
    Drive(Sensors &sensors);

  private:
    Sensors &sensors;
};

Sensorsこれにより、静的にコンパイルする方法で自由に実装できます。「制限」は、依存関係の注入を静的に定義/型指定する必要があることです。利点は、究極の柔軟性とゼロ オーバーヘッドです。たとえば、仮想メンバー関数テンプレートを使用できませんでしたが、これをSensorsポリシーとして使用できます。

struct TestSensors {
    int get(int)      { return 9;  } 
    int set(int, int) { return -9; } 

    template<typename OutputIterator>
    OutputIterator sensors(OutputIterator out) const {
        int available[] = { 7, 8, 13, 21 };
        return std::copy(std::begin(available), std::end(available), out);
    }
};

using TestDrive = Drive<TestSensors>;
于 2015-10-18T21:42:24.183 に答える