私はドファクトリー、ウィキペディア、そして多くのサイトで多くの記事を読んでみました。ブリッジパターンとストラテジーパターンの違いがわかりません。
私はそれらの両方が抽象化をその実装から切り離し、実行時に実装を変更できることを知っています。
しかし、どのような状況で戦略を使用すべきか、またはどのような状況でブリッジを使用すべきかはまだわかりません。
私はドファクトリー、ウィキペディア、そして多くのサイトで多くの記事を読んでみました。ブリッジパターンとストラテジーパターンの違いがわかりません。
私はそれらの両方が抽象化をその実装から切り離し、実行時に実装を変更できることを知っています。
しかし、どのような状況で戦略を使用すべきか、またはどのような状況でブリッジを使用すべきかはまだわかりません。
セマンティクス。ウィキペディアから:
ストラテジーパターンのUMLクラス図は、ブリッジパターンの図と同じです。ただし、これら2つのデザインパターンは、意図が同じではありません。ストラテジーパターンは行動を目的としていますが、ブリッジパターンは構造を目的としています。
コンテキストと戦略の間の結合は、ブリッジパターンでの抽象化と実装の間の結合よりも緊密です。
私が理解しているように、外部ソースから提供される可能性のある動作を抽象化する場合は戦略パターンを使用し(たとえば、configはプラグインアセンブリをロードするように指定できます)、使用する場合はブリッジパターンを使用しますコードを少しすっきりさせるための同じ構成。実際のコードは非常によく似ています。わずかに異なる理由でパターンを適用しているだけです。
ブリッジ パターンは構造パターンです (ソフトウェア コンポーネントをどのように構築しますか?)。戦略パターンは動的パターンです (ソフトウェアで動作を実行するにはどうすればよいですか?)。
構文は似ていますが、目的は異なります。
私も同じことを考えていましたが、最近ブリッジを使用する必要があり、ブリッジは戦略を使用してコンテキストに抽象化を追加しているため、後でクライアントを変更せずにさらに変更を加えることができることに気付きました。抽象化なしで Strategy を使用する場合、設計はそれほど柔軟ではなく、後でクライアントに変更が必要になる場合があります。しかし、ブリッジ全体を使用すると、設計はさらに柔軟になります。ここでは、ストラテジーからブリッジに移行することで柔軟性が向上することがわかります。また、「ビザ」と「マスター」はカードだけでなく、電話やチップでも利用できるようになったと想定しています。ブリッジを使用すると、そのサポートを追加するのがはるかに簡単になります。
ストラテジー:
意図は、実行時に動作を交換する機能です
class Context {
IStrategy strategyReference;
void strategicBehaviour() {
strategyReference.behave();
}
}
橋
意図は、実装から抽象化を完全に切り離すことです
interface IAbstraction {
void behaviour1();
.....
}
interface IImplementation {
void behave1();
void behave2();
.....
}
class ConcreteAbstraction1 implements IAbstraction {
IImplementation implmentReference;
ConcreteAbstraction1() {
implmentReference = new ImplementationA() // Some implementation
}
void behaviour1() {
implmentReference.behave1();
}
.............
}
class ConcreteAbstraction2 implements IAbstraction {
IImplementation implmentReference;
ConcreteAbstraction1() {
implmentReference = new ImplementationB() // Some Other implementation
}
void behaviour1() {
implmentReference.behave2();
}
.............
}
ブリッジ: (構造パターン)
ブリッジ パターンは、抽象化と実装を分離し、両方を個別に変更できるようにします。
次の場合にこのパターンを使用します。
戦略: (行動パターン)
戦略パターンを使用すると、実行時に一連のアルゴリズムから複数のアルゴリズムを切り替えることができます。
次の場合に戦略パターンを使用します。
関連記事:
パターンの比較(意図の違いなど)についてすでに述べたことに加えて、ブリッジパターンも、抽象化階層側を変更できるように意図的に構造化されています。C#のような言語では、これは、既存のコンシューマーに問題を引き起こさない意図されたバリエーションを許可する方法として、仮想メソッドを含む抽象化ベースがあることを意味する場合があります。それ以外は、2つのパターンはほとんど同じように見えるかもしれません。
戦略パターンに関するwikiから
ストラテジーパターンのUMLクラス図は、ブリッジパターンの図と同じです。ただし、これら2つのデザインパターンは、意図が同じではありません。ストラテジーパターンは行動を目的としていますが、ブリッジパターンは構造を目的としています。
コンテキストと戦略の間の結合は、ブリッジパターンでの抽象化と実装の間の結合よりも緊密です。
戦略パターンは、実行時にアルゴリズムまたは戦略をプラグインする場合に使用されます。パターンのカテゴリは、オブジェクトの動作を扱うことも意味します。一方、ブリッジは構造パターンであり、オブジェクトの構造階層を扱います。抽象化と実装の間に洗練された抽象化を導入することで、実装から抽象化を分離します。洗練された抽象化は、プラグインされた実行時戦略 (In Strategy パターン) と混同される可能性があります。ブリッジ パターンは、n 個のクラスを作成しないようにするメカニズムを提供することで、構造的な側面に対処します。