Java ブリッジ設計パターンを使用して抽象化を実装からエレガントに分離する方法

はじめに

Java ブリッジ パターン (ブリッジ パターンとも呼ばれます) (ブリッジ パターン) は、抽象化と実装を独立して変更できるように分離する設計パターンです。一連の密接に関連したクラスを 2 つの個別の階層に分割し、1 つは抽象クラスまたはインターフェイスを含み、もう 1 つは実装クラスを含みます。ブリッジ パターンでは、抽象クラスと実装クラスを独立して変更できるため、疎結合が実現されます。

## Java では、ブリッジ パターンは通常、インターフェイスを使用して抽象部分を定義し、抽象クラスを使用して部分的な実装を実装し、それらを組み合わせて結合します。抽象部分には、参照の一部を実装する場合のみが含まれます。実装部分はインターフェイスを実装します。

Java ブリッジ モードは次の 4 つの役割に分かれています。

• 抽象化役割 (Abstraction) : 抽象化されたインターフェイスを定義し、参照を維持します。
  ##拡張抽象ロール (洗練された抽象化): 拡張抽象ロール (通常は抽象ロールのサブクラス) は、抽象ロールにビジネス メソッドを実装します。
• # 実装ロール (実装者): 実装ロールのインターフェイスを定義します。このインターフェイスは、抽象ロールのインターフェイスと完全に一致している必要はありません。実際、これら 2 つのインターフェイスは完全に異なっていてもかまいません。

#具体的な実装者: 具体的な実装者は、実装されたロール インターフェイスを実装し、特定のビジネス ロジックを完成させます。

• #実装
• #たとえば、次のようになります。電子商取引 Web サイトでは、Alipay、WeChat 支払い、UnionPay 支払いなどの複数のサポート方法をサポートする必要がある場合があります。ブリッジ モードを使用すると、ユーザーのニーズに合わせてさまざまな支払い方法を簡単に追加または切り替えることができます。
  実装役割

public interface PaymentImplementor {
    /**
     * 支付
     *
     * @param amount
     */
    void processPayment(double amount);
}

具体的な実装の役割

public class AliPaymentImplementor implements PaymentImplementor {
    /**
     * 支付
     *
     * @param amount
     */
    @Override
    public void processPayment(double amount) {
        System.out.println("支付宝支付:" + amount + "元...");
    }
}
public class WechatPaymentImplementor implements PaymentImplementor {
    /**
     * 支付
     *
     * @param amount
     */
    @Override
    public void processPayment(double amount) {
        System.out.println("微信支付:" + amount + "元...");
    }
}
public class UnionpayPaymentImplementor implements PaymentImplementor {
    /**
     * 支付
     *
     * @param amount
     */
    @Override
    public void processPayment(double amount) {
        System.out.println("银联支付:" + amount + "元...");
    }
}

抽象的な役割

public abstract class Payment {
    protected PaymentImplementor implementor;
    public Payment(PaymentImplementor implementor) {
        this.implementor = implementor;
    }
    /**
     * 支付
     *
     * @param amount
     */
    public abstract void pay(double amount);
}

拡張された抽象的な役割

public class OnlinePayment extends Payment{
    public OnlinePayment(PaymentImplementor implementor) {
        super(implementor);
    }
    /**
     * 支付
     *
     * @param amount
     */
    @Override
    public void pay(double amount) {
        System.out.println("开始在线支付...");
        implementor.processPayment(amount);
        System.out.println("在线支付完成...");
    }
}

テスト

public class Demo {
    public static void main(String[] args) {
        // 支付宝支付
        PaymentImplementor paymentImplementor = new AliPaymentImplementor();
        Payment payment = new OnlinePayment(paymentImplementor);
        payment.pay(100);
        System.out.println();
        // 微信支付
        paymentImplementor = new WechatPaymentImplementor();
        payment = new OnlinePayment(paymentImplementor);
        payment.pay(101);
        System.out.println();
        // 银联支付
        paymentImplementor = new UnionpayPaymentImplementor();
        payment = new OnlinePayment(paymentImplementor);
        payment.pay(102);
    }
}

このコードは、ブリッジ パターンを実装する簡単な例です。そのうち、Payment は抽象クラス、OnlinePayment はそのサブクラス、PaymentImplementor はインターフェイス、AliPaymentImplementor、UnionpayPaymentImplementor、WechatPaymentImplementor はすべてその実装クラスです。このように、 Payment クラスの PayImplementor インターフェイスは分離されており、独立して開発および拡張できます。

この例では、Payment クラスは抽象的でインスタンス化できませんが、OnlinePayment サブクラスを通じてインスタンス化されます。OnlinePayment サブクラスは pay メソッドをオーバーライドします。そして、PaymentImplementor インターフェイスを実装するクラスから派生したimplementor.processPayment メソッドを呼び出します。ああ、たとえば、AliPaymentImplementor、UnionpayPaymentImplementor、WechatPaymentImplementor です。このメソッドを使用すると、PaymentImplementor インターフェイスの実装クラスを OnlinePayment クラスに動的に挿入できます。これにより、OnlinePayment クラスを変更せずにさまざまな支払い方法を実現できます。

概要

利点

抽象部分と実装部分を分離して、独立して変更できるようにします。これにより、システムの柔軟性とスケーラビリティが向上します。

抽象インターフェイスを通じてオブジェクト間の関係を管理することは、オブジェクト指向プログラミングの原則により一致しており、システムの保守と管理が容易になります。理解します。

• ブリッジ パターンは継承の使用を回避できます。クラス爆発の問題は、組み合わせ関係を使用しているように見えるため発生します。

• 欠点

• ブリッジ モードではシステムの複雑さが増し、追加の抽象化レイヤーが必要になります。抽象化レイヤーにより、システム設計が複雑になる可能性があります。ブリッジ インターフェイスと実装クラスが適切に設計されていない場合、システムの結合が増加する可能性があります。

アプリケーション シナリオ

• クラスが複数ある場合寸法を変更する場合 (たとえば、シェイプ クラスの色やサイズが異なる場合)、ブリッジ パターンを使用してそれらを分離し、システムをより柔軟にすることができます。

• さまざまなサイズをサポートする必要がある場合プラットフォーム、データベース、またはプロトコルに応じて、ブリッジ パターンを使用してこれらの実装の詳細をカプセル化し、クライアントと実装の部分を相互に影響を与えることなく個別に変更できるようにします。

動的に切り替える必要がある場合実行時の実装では、ブリッジ モードを使用してこの切り替えを実現できます。

以上がJava ブリッジ設計パターンを使用して抽象化を実装からエレガントに分離する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。