問題タブ [policy-based-design]

名前付きテンプレート引数は、間違いなく C++ の非常に重要な機能です。つまり、デフォルトの引数を持つ多くのテンプレート パラメーターを持つクラス テンプレートが与えられた場合、この機能により、ユーザーはこれらのパラメーターの任意のサブセットに引数を提供できます。Vandervoorde と Josuttis による「C++ Templates: the Complete Guide」では、セクション 16.1全体を名前付きテンプレート引数の効果の達成に費やしています。

同書のセクション 13.9には、言語に追加される可能性が高い機能の 1 つとして名前付きテンプレート引数がリストされています。この見積もりが 12 年前にさかのぼるという事実と、この機能の優れた有用性の両方を考えると、名前付きテンプレート引数が最新の標準に組み込まれたか、および/または現代のコンパイラに実装されているかを調べたいと思います。

最初の質問に対する答えが否定的である場合、何が欠けているのかを理解したいと思います。つまり、なぜこの機能の必要性は、私が認識しているほど悪くないのですか?

この投稿では、ポリシーベースの設計の単純な実装に関する問題を説明し、代替実装を提案し、提案された実装を分析し、分析でさまざまな要因に適切な重みを与えるように助けを求めることで構成されています。文章が長くなってしまい申し訳ありませんが、引き続きよろしくお願いいたします。

問題の説明

次のようにポリシーベースの設計を使用するとします。

上記のホスト クラスとポリシーの間にはある程度の結合があります。署名がFooPolicy::foo変更された場合は、それに応じてコードAlg::operator()を変更する必要があります。

ポリシー クラスにインターフェイスの選択の自由度が与えられると、結合はさらに緊密になります。たとえば、パラメータなしで、または1 つの整数パラメータを使用して実装できるとします (この場合の実装は、こちらで提案されFooPolicyています)。foofoo

明らかに、異なるインターフェースを持つポリシー クラスを追加するたびに、ディスパッチ メカニズムを更新する必要があり、複雑になる可能性があります。

提案されたデザイン

アルゴリズムが、ポリシー クラスの関数メンバーが引数を受け入れる代わりにデータを取得するために使用できるインターフェイスを提供する設計を検討しています。上記の例では、次のようになります。

分析

この設計により、ポリシーは、対応するServicesクラスのパブリック インターフェイスを使用して取得できるデータを自由に使用できます。この例では、を使用しParamFoo::fooてアルゴリズムを取得しました。ホスト クラスは引数なしで呼び出すだけで、これは変更されても変更する必要はありません。これが、私たちが望んでいた分離です。argFooPolicyServices::getArgFooPolicy::fooFooPolicy::foo

この設計には 2 つの欠点があります。

1. argAlgはローカル変数ではなく の状態の一部になりました。これは、変数はできるだけ遅く定義する必要があると述べている、 Effective C++の項目 26にAlg::operator()反します。ただし、追加の初期化のコストがアルゴリズムを実行するコストと比較して無視できる場合、その項目の推論は適用されません。arg

2. ポリシー クラスは状態を取得しました。そのため、静的メンバー関数を呼び出すだけではポリシーを使用できません。

質問

3 つの質問:

1. 提案された設計によって達成されるデカップリングは、上記の 2 つの欠点に値するものですか?

2. 私が見落としている欠点はありますか？

3. 提案されたデザインに名前はありますか？

@Useless の返信に基づいて、更新された実装を次に示します。Servicesこの実装により、ステートレスなポリシー クラスを持つことが可能になりますが、ポリシーが使用されるたびに同じ参照をオブジェクトに渡すというオーバーヘッドがあります。

Builderを構築するクラスがありますObject。の内臓の一部をポリシー オブジェクトに置き換える計画がありObjectます。たとえば、いくつかのコンテナ タイプを設定できるようにしStorageます。具体的には、 を使用して のBuilderポリシー オブジェクトを設定しObject、何も指定されていない場合はデフォルトにフォールバックします。私の頭の上から、次のようなもの：

問題の要点は、typedef を一種の「テンプレート変数」として使用して、ユーザー定義のテンプレート変数を格納できるかどうかです。

より多くのコンテキストを提供するために、json 構成ファイルからBuilderのかなり複雑な作成をサポートし、Object各キーとその検証を個々のメソッドに委譲する必要があります。静的な名前付きコンストラクターBuilder::from_config(...)とそれを行うメソッドがありますが、構成Builder::load_config(...)ファイルからのポリシー オブジェクトの選択をサポートしたいと考えています。それ以外の場合は、メソッドにテンプレートを追加するだけで問題ないBuilder::init()ので、ポリシー オブジェクトを に渡すことができますObject。