橋の設計パターン

やあ！私たちはこれからも、デザイン パターンという広範で非常に重要な有益なトピックを掘り下げていきます。今日はブリッジパターンについてお話しましょう。他のパターンと同様、ブリッジ パターンは、開発者がソフトウェア アーキテクチャを設計するときに遭遇する典型的な問題を解決するのに役立ちます。今日は、このパターンの特徴とその使用方法を調べてみましょう。

ブリッジパターンとは何ですか？

ブリッジパターンは構造設計パターンです。言い換えれば、その主な仕事は、クラスとオブジェクトから本格的な構造を作成することです。ブリッジは、1 つ以上のクラスを別の階層 (抽象化と実装)に分割することでこれを実現します。一方の階層の機能が変更されても、もう一方の階層の変更は伴いません。それはそれでいいのですが、この定義は非常に広義であり、「ブリッジ パターンとは何ですか?」という最も重要な質問には答えていません。実際の応用例も理解しやすいと思います。それでは早速、ブリッジ パターンの古典的なシナリオを作成してみましょう。Shape一般的な幾何学的図形を表す 抽象クラスがあります。

• シェイプ.java

  
  public abstract class Shape {
     public abstract void draw();
  }
  

  三角形や四角形などの図形を追加することに決めたら、それらにShapeクラスを継承させます。

• 長方形.java:

  
  public class Rectangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
     }
  }
  

• トライアングル.java:

  
  public class Triangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing triangle");
     }
  }
  

色の概念を導入するまでは、すべてが単純に見えます。つまり、各図形には独自の色があり、メソッドの機能はdraw()この色に依存します。メソッドをさまざまに実装するにはdraw()、形状と色の組み合わせごとにクラスを作成する必要があります。3 つの色がある場合、TriangleBlack、TriangleGreen、TriangleRed、RectangleBlack、RectangleGreenの6 つのクラスが必要ですRectangleRed。6クラスはそれほど大きな問題ではありません。しかし！新しい形や色を追加する必要がある場合、クラスの数は指数関数的に増加します。この状況から抜け出すにはどうすればよいでしょうか？フィールドに色を保存し、条件ステートメントを使用してすべてのオプションを列挙することは、最良の解決策ではありません。良い解決策は、色を別のインターフェイスに移動することです。。言ったらすぐに完了です。 、 、Colorの 3 つの実装を備えたインターフェイスを作成しましょう。 BlackColorGreenColorRedColor

• カラー.java:

  
  public interface Color {
     void fillColor();
  }
  

• BlackColor.java:

  
  public class BlackColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in black color");
     }
  }
  

• GreenColor.java

  
  public class GreenColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in green color");
     }
  }
  

• RedColor.java

  
  public class RedColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in red color");
     }
  }
  

  Color次に、クラスにフィールドを追加しますShape。コンストラクターでその値を取得します。

• シェイプ.java:

  
  public abstract class Shape {
     protected Color color;
    
     public Shape(Color color) {
         this.color = color;
     }
  
     public abstract void draw();
  }
  

  color実装では変数を使用しますShape。これは、シェイプがインターフェイスの機能を使用できるようになったということを意味しますColor。

• Rectangle.java

  
  public class Rectangle extends Shape {
  
     public Rectangle(Color color) {
         super(color);
     }
  
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
         color.fillColor();
     }
  }
  

タダ！さまざまな色や形を無限に作成できるようになり、クラスの数は直線的にのみ増加します。フィールドColor colorは、2 つの別個のクラス階層をつなぐ架け橋です。

ブリッジの構築方法: 抽象化と実装

ブリッジ パターンを表すクラス図を見てみましょう。 ここでは、互いの機能に影響を与えることなく変更できる 2 つの独立した構造がわかります。私たちの場合には：

• Shape抽象化はクラスです
• RefinedAbstraction はTriangleとRectangleクラスです
• Color実装者はインターフェースです
• ConcreteImplementor はBlackColor、GreenColorおよびRedColorクラスです。

このShapeクラスは抽象化、つまりさまざまな色で図形を塗りつぶすことを管理するメカニズムであり、Colorインターフェイス (実装者) に委任されます。およびクラスはTriangle、クラスRectangleによって利用可能になるメカニズムを使用する具象クラスですShape。 BlackColor、GreenColorおよび は、RedColor実装階層内の具体的な実装です。

ブリッジパターンを使用する場所

このパターンを使用する大きな利点は、一方の階層のロジックを壊すことなく、一方の階層の関数クラスを変更できることです。また、このアプローチはクラス間の結合を減らすのにも役立ちます。このパターンを使用する場合の主な要件は、「指示に従う」ことです。どの指示も無視しないでください。そのために、ブリッジ パターンを必ず使用する必要がある状況を考えてみましょう。

1. 2 つの概念 (形状と色など) の組み合わせに基づいてエンティティの数を拡張する必要がある場合。

2. 単一責任の原則を満たさない大規模なクラスを、機能が限定された小さなクラスに分割する場合。

3. プログラムの実行中に特定のエンティティのロジックを変更する必要がある場合。

4. クラスまたはライブラリのクライアントから実装を隠す必要がある場合。

このパターンを使用するときは、コードに追加のエンティティが追加されることを常に念頭に置いてください。形状が 1 つしかなく、使用可能な色が 1 つまたは 2 つしかないプロジェクトでこのパターンを使用するのは意味がありません。

パターンの長所と短所

他のパターンと同様、ブリッジには長所と短所の両方があります。 ブリッジ パターンの利点:

1. コードのスケーラビリティが向上します。プログラムの別の部分で何かが壊れるのを恐れることなく、機能を追加できます。
2. エンティティの数が 2 つの概念 (形状と色など) の組み合わせに基づいている場合に、サブクラスの数が削減されます。
3. これにより、抽象化と実装という 2 つの別個の階層で個別に作業できるようになります。2 人の異なる開発者が、互いのコードの詳細を掘り下げることなく変更を加えることができます。
4. これにより、クラス間の結合が減少します。2 つのクラスが結合される唯一の場所はブリッジ (つまり、フィールドColor color) です。

ブリッジ パターンの欠点:

1. 特定の状況やプロジェクトの全体的な構造によっては、プログラムのパフォーマンスに悪影響を及ぼす可能性があります (たとえば、より多くのオブジェクトを初期化する必要がある場合)。
2. 2 つのクラスを切り替える必要があるため、コードが読みにくくなります。

戦略パターンとの違い

ブリッジ パターンは、別の設計パターン、つまり戦略と混同されることがよくあります。どちらも合成を使用し (例では図と色の集約を使用しましたが、Bridge パターンでは合成も使用できます)、作業を他のオブジェクトに委任します。しかし、それらの間には違いがあり、それは非常に大きいです。戦略パターンは行動パターンであり、まったく異なる問題を解決します。ストラテジではアルゴリズムを交換できるのに対し、ブリッジでは異なる実装間で選択するために抽象化を実装から分離します。つまり、戦略とは異なり、ブリッジはエンティティ全体または階層構造に適用されます。ブリッジ パターンは、開発者の武器となる可能性があります。重要なことは、それを使用する価値がある状況を特定し、他のパターンが適切な場合を認識することです。

• シングルトン
• 工場
• 抽象的な工場
• ファクトリーメソッド
• プロキシー
• アダプタ