JavaRush /Java Blog /Random-JA /橋の設計パターン

橋の設計パターン

Random-JA グループに公開済み
こんにちは!私たちは、デザイン パターンという、幅広く非常に役立つトピックについて理解を続けています。今日はブリッジについてお話します。他のパターンと同様に、Bridge は、開発者がソフトウェア アーキテクチャを設計する際に直面する一般的な問題を解決するのに役立ちます。今日はその機能を学び、その使用方法を見つけてみましょう。

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

Bridge パターンは構造設計パターンです。つまり、その主なタスクは、クラスとオブジェクトの完全な構造を作成することです。Bridge は、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");
       }
    }
「色」という概念を導入するまでは、すべてが単純に見えます。つまり、各 Figure は独自の色を持ち、メソッドの機能はそれに依存しますdraw()。メソッドをさまざまに実装するにはdraw()、色に対応する形状ごとにクラスを作成する必要があります。3 つの色がある場合、TriangleBlackTriangleGreenTriangleRedRectangleBlackRectangleGreenおよび の6 つのクラスがありますRectangleRed。6クラスというのはそれほど大したことではありません。しかし!新しい形や色を追加する必要がある場合、クラスの数は指数関数的に増加します。この状況から抜け出すにはどうすればよいでしょうか?フィールドに色を保存し、条件分岐を通じてオプションを試すことは、最良の解決策ではありません。良い解決策は、別のインターフェイスで色を表示することです。Colorインターフェースとその 3 つの実装 (BlackColorGreenColor)を作成しましょうRedColor
  • カラー.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次に、クラスにtype フィールドを追加しましょう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 color2 つの別個のクラス階層を相互接続するブリッジです。

ブリッジデバイス: 抽象化と実装とは何か

Bridge パターンを説明するクラス図を見てみましょう。 ブリッジデザインパターンの紹介 - 2ここでは、互いの機能に影響を与えることなく変更できる 2 つの独立した構造がわかります。私たちの場合は次のようになります。
  • 抽象化 - クラスShape;
  • RefinedAbstraction - クラスTriangleRectangle;
  • 実装者 - インターフェースColor;
  • ConcreteImplementor - クラスBlackColorGreenColorおよびRedColor
このクラスは、Shape抽象化 (さまざまな色で図の色付けを制御するメカニズム) を表し、実装をインターフェイスに委任しますColor。クラスは、そのクラスが提供するメカニズムを使用する実際のオブジェクトTriangleです。 、および- 実装ブランチ内の特定の実装。それらはしばしばプラットフォームと呼ばれます。 RectangleShapeBlackColorGreenColorRedColor

Bridge パターンはどこで使用されますか?

このパターンを使用する大きな利点は、別のブランチのロジックを壊すことなく、あるブランチ内のクラスの機能を変更できることです。このアプローチは、プログラム クラスの結合を減らすのにも役立ちます。パターンを使用するための主な条件は「指示に従う」ことです。パターンをどこにも貼り付けないでください。実際に、どのような場合に Bridge を使用する必要があるかを考えてみましょう。
  1. エンティティの数を 2 つの方向 (幾何学的形状、色) に拡張する必要がある場合。

  2. 単一責任の原則を満たさない大規模なクラスを、狭いプロファイル機能を備えた小さなクラスに分割する場合。

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

  4. 必要に応じて、クラス (ライブラリ) クライアントから実装を非表示にします。

パターンを使用するたびに、追加のエンティティがコードに追加されることを覚えておく必要があります。幾何学図形が 1 つしかなく、可能な色が 1 つまたは 2 つしかないプロジェクトでパターンを使用するのは完全に論理的ではありません。

パターンの長所と短所

他のパターンと同様、ブリッジには長所と短所の両方があります。 ブリッジの利点:
  1. コードのスケーラビリティが向上します。プログラムの別の部分で何かが壊れることを恐れることなく、機能を追加できます。
  2. サブクラスの数を減らします - エンティティの数を 2 つの方向 (たとえば、形状の数と色の数) に拡張する必要がある場合に機能します。
  3. 抽象化と実装の 2 つの独立したブランチで個別に作業できるようになります。これは、2 人の異なる開発者が互いのコードの詳細を掘り下げることなく実行できます。
  4. クラスの結合を減らす - 2 つのクラスが接続される唯一の場所はブリッジ (フィールドColor color) です。
ブリッジの欠点:
  1. 特定の状況とプロジェクト全体の構造によっては、プログラムの生産性に悪影響を及ぼす可能性があります (たとえば、より多くのオブジェクトを初期化する必要がある場合)。
  2. クラス間を移動する必要があるため、コードが読みにくくなります。

ストラテジーパターンとの違い

Bridge パターンは、別のデザイン パターンである Strategy と混同されることがよくあります。どちらも、作業を他のオブジェクトに委任することで合成を使用します (形状と色の例では集約を使用しましたが、Bridge パターンでは合成も使用できます)。しかし、それらの間には違いがあり、それは非常に大きいです。戦略パターンは行動パターンであり、まったく異なる問題を解決します。ストラテジではアルゴリズムの互換性が可能ですが、ブリッジでは抽象化が実装から分離され、異なる実装間の選択が可能になります。つまり、Bridge は、Strategy とは異なり、構成全体または階層構造に適用されます。Bridge パターンは、開発者の武器庫の中で優れた武器となる可能性があります。重要なのは、それを使用する価値がある状況を見つけるか、他のパターンを使用することです。他のテンプレートにまだ慣れていない場合は、次の資料をお読みください。
コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION