戦略パターンと委任パターンの違い

Question

戦略パターンと委任パターン（代理人ではない）の違いは何ですか？

Answer 1

戦略パターンは、共通のソフトウェア問題に対する非常に特殊な設計ソリューションです。 戦略パターンは、戦略（または戦略の名前の一部としての）と呼ばれるインターフェースが

• であることを意味します。このインタフェースにはexecute（）というメソッドが必要です。
• Strategyインターフェイスを実装するConcreteStrategyA、ConcreteStrategyBなどの1つ以上の具体的なクラスがあります。
• も戦略

代表団がパターンよりも元本で含まれているコンテキストクラスがあるはずです。委任は、単一のオブジェクトがすべてを担当するのではなく、責任を他のオブジェクトに委任することを意味します。これが一般的なテクニックである理由は、カップリングを減らし、結束性を高めることによって、ソフトウェア開発の2つの基本的な原則を強制するということです。

パターンを心配する必要はありません。プリンシパルに焦点を当て、解決策が改善されると感じたら、より良いマウストラップがあるかどうかをパターンを見てください。あなたはパターンの代わりに、校長に焦点を当てる場合は、あなた自身がすべてのパターンで失われたとパターンを実装するためのパターンを実装するばかりでしょう...

Answer 2

「委任」は実際にはデザインパターンではなく、コンポーネントAがタスクBをどのような種類のタスクに委譲するかという一般的なプログラミング手法です。多くのコンテキストで委譲を使用できます。

戦略パターンは、典型的には、実装の詳細として委任を頻繁に使用する特定のパターンです。

たとえば、戦略のパターンを実装して、戦略インタフェースのさまざまな実装を持って、実行時に適切な実装を選択することを含む

strategy.execute(x) 

戦略パターンを使用して、それを呼び出すことがあります。その実装を呼び出す行為は委任です。

だから、それはどちらでもない/またはコンセプトは無料です。

Answer 3

は、ここで考えます：

参加者は時（委譲クラスを模倣します少なくとも私がそれらを使ったように、それが正規の方法であるかどうかは確信していませんが、それは私が通常それを行う方法です）。基本的に、複数のエントリポイント（メソッド）を持つクラスがあり、実行時に実装を変更したい場合は、同じインターフェイスを実装するデリゲートを作成します。

実行時に交換できるようにしたいクラスの部分がある場合は、単一のメソッドインタフェース（executeCalculationなど）でStrategyクラスを作成し、それを集約コンポーネントにしますそのクラスを含む。

要約すると、戦略は単一の動作を含み、代理人は一連の動作を実装し、代理人を使用して戦略を実装できます。

Answer 4

戦略パターンとデリゲートを意味するなら、関数/ lambdasが引数として渡されるので、少なくともがあります。少なくとも、デリゲートのためにコンパイルする必要があるクラスに関してオーバーヘッドは少なくなります。

私は実際にこのページは私がStrategyパターンを使用してどのように動作するかを知っている引数