問題タブ [strategy-pattern]

たとえば、基本抽象クラスがあるとします

そして、システムに持つ動作/アルゴリズムを持っています

などなど

これで、IFlyable、ISwimmable などの具象を使用して、それを実装する複数のクラスができました。

などなど

1 つは、Foo の基本クラスで戦略パターンを使用して動作を交換することです。

デコレーターパターンを使用して特定の動作でラップすることもできますが、デコレーターは基本クラスでラップするため、後でオブジェクトにさらに動作を追加する場合、基本クラスに触れずにオープンクローズ原則を実際に機能させるにはどうすればよいですか。これらの動作は、たとえばデコレータを呼び出すだけでなく、さらに追加すると異なるシグネチャを持つ可能性があるため

私の質問は、動作を追加する場合、どうすれば基本クラスを変更せずに IWeaponBehavior、ISomeBehaviour をクラスに追加できるかということだと思います。

たとえば、私はクラスを持ちたいです

しかし、私はそれにISomeBehaviourのいくつかの動作を与えたいのですが、これらの種類の動作でそれをラップすると言うことができる方法はありますか、またはここではConcreteFooがこれらの動作でラップし、具体的なxyzにインターフェースを実装するのではなく何かをしますこれにより、swimbehavior、nullbehaviour などの非常に多くの種類の具体的な動作クラスを実装することになりますが、そこから抜け出す方法はありません。

デザインパターンでこれを行う方法はありますか? それはほとんどパターンのハイブリッドのように見えます。

アヒルのように歩き、アヒルのように鳴くが、バッテリーが必要な場合は、抽象化に問題があるように思えます。

これが理にかなっていることを願っています。

ファクトリーパターンと戦略パターンの違いを説明できる人はいますか?

私にとって、両方とも追加のファクトリークラス（ファクトリーパターンで製品のオブジェクトを作成する）以外は同じように見えます

C++ テンプレートを使用して Strategy ファンクターを渡し、関数の動作を変更しています。それは正常に動作します。私が渡すファンクターは、ストレージを持たないステートレス クラスであり、() 演算子を従来のファンクターの方法でオーバーロードするだけです。

私はこれを頻繁に行っており、うまく機能しており、多くの場合、6 つまたは 7 つのテンプレート化されたファンクターを渡してテンプレートを作成しています!

ただし、コードのエレガンスと効率の両方について心配しています。ファンクターはステートレスであるため、Operation() コンストラクターはフリーであり、ファンクターの評価はインライン関数と同じくらい効率的であると想定していますが、すべての C++ プログラマーと同様に、私は常にいくつかのしつこい疑問を抱いています。

私の 2 番目の質問は、別のファンクター アプローチを使用できるかどうかです。() 演算子をオーバーライドせず、コンストラクター内のすべてを副作用として実行する方法です。何かのようなもの：

ファンクターの「作業」としてコンストラクターを使用している人を見たことがありませんが、機能するはずです。何か利点はありますか？デメリットは？私は奇妙な二重括弧 "Operator()(a)" の削除が好きですが、それはおそらく美的です。

テンプレートメソッドパターンと戦略パターンの違いは何ですか?

私が知る限り、それらは 99% 同じです。唯一の違いは、テンプレート メソッド パターンが基本クラスとして抽象クラスを持っているのに対し、戦略クラスは各具象戦略クラスによって実装されるインターフェイスを使用することです。

しかし、クライアントに関する限り、それらはまったく同じ方法で消費されます - これは正しいですか?

戦略パターンが実際に何であるかについて誰かとオタクの戦いがあり、問題を解決するには専門家が必要です.

同じインターフェースを維持しながら、実行時にクラスの中身 (動作など) を交換できるストラテジー パターンについては、両者とも同意しています。しかし、彼女の主張は、「[アルゴリズム] が戦略であるためには、同じ結果が得られなければならない」というものです。私の主張は、クラスの「アルゴリズム」またはロジックを交換すると、オーバーライドされた操作の結果が異なることを意味する可能性がありますが、それでも戦略パターンの目的、意図 (および分類) を満たしているということです。

コメント付きの彼女のコード例:

あなたの定義によれば、クラスのサブクラスは戦略になります。これらは同じメソッド定義 (シグネチャ) を持っているため、交換可能です。

最初の 2 つは戦略です。どんな入力に対しても、彼らはあなたに正確に同じ答えを与えるからです。最後のものはそうではありません。int が得られるからといって、それが戦略になるわけではありません。彼らは同じことを「行う」必要があります。

それらを戦略にするためだけに「より高い」抽象化用語を使用することはできません。

これらはすべて「数学」を行いますが、すべて「同じ」ことを異なる方法で行っているわけではありません。それが戦略の本質です。

それで、誰が正しいですか？

C#でテンプレート/抽象クラスのコンストラクターの戦略を実装する最良の方法は何ですか? コンストラクター内の文字列の解析に基づいたクラスがいくつかあります。解析は、キーと値のペアのリストを作成する静的メソッドで行われ、すべてのクラスに共通ですが、一部のフィールドはすべてのクラスに共通であるため、抽象テンプレート クラスを使用します。

問題は、抽象基本クラスのコンストラクターの実装を継承する方法が見つからないことです。それ以外の場合は、基本クラスにコンストラクター戦略を実装し、一部の抽象メソッド内でリストの処理を強制します。

編集：テンプレートクラスの動作しないコードを追加

単一責任の原則が、すべてのオブジェクトには変更する理由が 1 つ必要であり、Strategy パターンで実装された単一の戦略クラス (定義による) に、さまざまな理由で変更できる複数のメソッドがあると述べている場合、それは実装が不可能であることを意味しますか? SRPに違反することなく戦略パターン？

これらの用語は同じですか、または依存性注入と戦略パターンの間に重要な違いはありますか? 私には、Martin Fowler が戦略パターンの名前をよりキャッチーな名前に変更したように思えますが、何か不足していますか?