1430 次
1 に答える
2
いいえ、「このような」プロジェクトのデザイン パターンはありません。
デザインパターンはゴールではありません。
だから、いくつかの推測をまっすぐにしましょう:
- 軽量のコードが必要な場合 (そうしないと、Java を使用することになります)
- 保守可能なコードが必要です (それ以外の場合は、スパゲッティで問題ないため)
- あなたは慣用的なコードが欲しい
これが私がすることです:
- 個別のヘッダーでクラスを宣言する
- 前方定義を使用してヘッダー結合を減らします
- 対応するソース ファイルに実装を移動する
不要な実装の依存関係をヘッダー ファイルから除外します。必要に応じて、ここで Pimpl イディオムを使用します。
たとえば、ライブラリ X を使用して実装
Y::frobnicate
する場合はlibX.h
、Y.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 に答える