1.定義

また、ブリッジモードと呼ばれるブリッジモード（ブリッジパターン）は、以下のように定義されている比較的単純なパターンです。

二つの独立して変えることができるように、その実装から抽象化を切り離します。
抽象と切り離され、その2は、独立して変化できること。
注：デカップリングに焦点

2、図タイプ

焦点は「デカップリング」ブリッジモードであることは、我々がフォーカスのデカップリング方法を理解する必要があります。図ジェネリッククラスブリッジパターンは以下の:( クラス間の集約、継承、オーバーライドメソッド）

ブリッジモード4つの役割：

抽象化（抽象的役割）：その主な責任は役割の実現への参照を保持したまま、一般の役割を行動の役割を定義することです
これは抽象クラスです。
実装者（文字の実現は）：それは必要な行動とプロパティの役割を定義するインタフェースまたは抽象クラスです。
RefinedAbstractionは（抽象的役割を修正）：それは改正される抽象的な役割の実現の役割を指します。
ConcreteImplementor（文字の特定の実装）：その方法と抽象クラスまたはインタフェースによって定義されたプロパティ。
コアは、抽象文字のリファレンス実装の役割の一部または抽象実装の役割は、実装の役割によって行われます。

達成するために3、

役割の実装者の3.1実現

public interface Implementor {

    void doSomething();

    void doAnything();
}

役割ConcreteImplementorの3.2具体的な実現

public class ConcreteImplementor1 implements Implementor {
    @Override
    public void doSomething() { /*业务逻辑处理*/ }

    @Override
    public void doAnything() { /*业务逻辑处理*/ }
}

public class ConcreteImplementor2 implements Implementor {
    @Override
    public void doSomething() { /* 业务逻辑 */ }

    @Override
    public void doAnything() { /* 业务逻辑 */ }
}

役割の定義された2つの具体的な実現の上で - 二つの異なるビジネスロジックを表します。

3.3抽象文字抽象化

public abstract class Abstraction {
    // 定义对实现化角色的引用
    private Implementor imp;
    // 约束子类必须实现该构造函数
    public Abstraction(Implementor _imp) {
        this.imp = _imp;
    }
    // 自身的行为和属性
    public void request() {
        this.imp.doSomething();
    }
    // 获得实现化角色
    public Implementor getImp() {
        return imp;
    }
}

なぜコンストラクタを追加しますか？答えは明確なアウトを定義しようとし、その後、指定された人物、達成するために同定されている人、特にそれらを達成するための作業を行う必要があり、サブクラスを思い出させるためです。我々は、サブインターフェースの役割の実現をたくさん持っている場合、それについて考え、その後、サブの束を達成。あなたは、コンストラクタで明確な実装を渡すためにしようとしていない場合は、コードは非常に明確です。

3.4修正された抽象的役割RefinedAbstraction

public class RefineAbstraction extends Abstraction {
    // 覆写构造函数
    public RefineAbstraction(Implementor _imp) {
        super(_imp);
    }
    // 修正父类的行为
    @Override
    public void request() {
        // 业务处理
        super.request();
        super.getImp().doAnything();
    }
}

4、利点

抽象化と分離：要約、これはブリッジモードの主な機能の分離では、それは提案された設計パターンを継承の欠点を解決するために完全です。このモードでは、それはもはや抽象化の固定レベルにバインドされた、抽象的制約を達成することはできません。
優れたスケーラビリティ：私たちの例を見ては、達成するために増加させたいですか？問題ありません！抽象的、何の問題が増加しないようにしたいです！外部被ばくの界面層限りは、そのような変更を可能にするように、我々は変更の可能性を最小限にする必要があります。
顧客への透過的な実装の詳細：顧客は、実現の詳細を気にしないが、それは抽象化のアグリゲーション層を介してパッケージを完了しました。

5、アプリケーションのシナリオ

適用されないか、継承のシナリオを使用したくない：適用できないか、そのような継承階層の移行ではなく、より洗練されたデザインの粒子のシナリオとして継承シナリオを使用したいブリッジモードを使用することを検討していません。
インターフェイスや抽象クラス不安定シナリオ：あなたは、インターフェイスが実装または継承することで、ビジネスのニーズを達成するために、不安定な希望であることを知って、それはろうそくの価値がある、それは比較がアプローチを失敗しています。
高い再利用シナリオの要件：デザインの微粒子継承の使用は親クラスによって制限されている一方で、大きな可能性があまりにも細かい粒度では不可能、再利用されました。

6つの注意事項

ブリッジモデルは非常に簡単です達成するために、このモードを使用して、どのように抽象を分割する際に、主な考慮事項は、連続を含まないことは、このモードを使用することを検討すべきである、それはまた、それをやって継承しますか？これは、ブリッジモードまたはパッケージの変化、増殖の危険を避けるために、最高の最小の論理ユニットを変更することが可能な要因限りパッケージに意図されています。そこで、システムの設計時に、継承は、N層のクラスを発見したブリッジモードを使用することを検討してください。

7つのベストプラクティス

継承フィーチャクラスは、それが何の欠点を持っていない、多くの利点を持っていますか？

強力な侵略は、親クラスのメソッドがあり、サブクラスにも、この方法を持っている必要があります。これは選択できません、問題のスケーラビリティを引き起こす可能性があります。

ここで説明するために単純な例です、父クラスはメソッドAを有し、息子はこのメソッドを継承した後、孫も、このメソッドを継承し、問題は親クラスのこのメソッドをオーバーライドするためにある日突然息子で、彼はそれを行うことを敢えて？絶対にありません！あなたが変更した場合の孫がAの上に父から継承されたメソッドを使用し、それはリスクが大きすぎること、息子と孫の関係を変更する必要があります！

ブリッジモードでは、この問題を解決するには、ブリッジパターンは、クラス間の弱い関係を説明しています。上記の例を続けると、父クラスは出して変更されることがメソッドを置くことができ、息子は橋があなたもこの方法を使用したくない息子サブクラスであっても、あまりにもこの方法で、孫に、過去にアクセスが乗る、この方法は非常に簡単である持っているサブクラス息子から、それは孫に影響を与えていない、重要ではありません、それは継承されていない方法！

悪い継承を言うことができない、それは非常に良いですが、欠点があり、我々はそれを継承することによって行われ、より明確に変更されないし、弱点を避けることができ、それは変更が発生するかどうか判断できない場合は、変化すると考えられている、その後、ブリッジモードによって解決され、これは完璧な世界です。

参考：「禅デザインパターン」