Bridge Pattern (bridge mode)

table of Contents

1. Definitions

2, FIG type

3, to achieve

3.1 realization of the role Implementor

3.2 concrete realization of the role ConcreteImplementor

3.3 abstract character Abstraction

3.4 amended abstract role RefinedAbstraction

4, the advantages

5, application scenarios

6 Notes

7 Best Practices


1. Definitions

Bridge mode (Bridge Pattern) also called bridge mode, is a relatively simple pattern, which is defined as follows:

  • Decouple an abstraction from its implementation so that the two can vary independently.
  • Abstract and decoupled, so that the two can vary independently.
  • Note: focus on decoupling

2, FIG type

The focus is on the bridge mode "decoupling" is we have to understand how the decoupling of focus. FIG generic class bridge pattern follows :( aggregation between classes, inheritance, override method )

Bridge mode four roles:

  • Abstraction (abstract role): Its main responsibility is to define the role of behavior, while preserving a reference to the realization of the role, the role of general
  • It is an abstract class.
  • The Implementor (realization of characters): It is the interface or an abstract class that defines the role of the required behavior and properties.
  • RefinedAbstraction (corrected abstract role): it refers to the role of the realization of the abstract roles to be amended.
  • ConcreteImplementor (specific implementation of the character): its methods and properties defined by abstract classes or interfaces.
  • Core: abstract character reference implementation part of the role or the role of abstract implementation is done by the implementation role.

3, to achieve

3.1 realization of the role Implementor

public interface Implementor {

    void doSomething();

    void doAnything();
}

3.2 concrete realization of the role ConcreteImplementor

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() { /* 业务逻辑 */ }
}

The above defined two concrete realization of the role - represent two different business logic. 

3.3 abstract character Abstraction

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;
    }
}

Why add a constructor? The answer is to remind subclass, you must do the work to achieve the specified persons, particularly those who have been identified to achieve, then try to define clear out. Think about it, if we have a lot of realization of the role of sub-interfaces, and then a bunch of sub achieve. If you do not try to pass a clear implementers in the constructor, the code is very clear.

3.4 amended abstract role RefinedAbstraction

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

4, the advantages

  • Abstraction and separation: Abstract and this is separation of the main features of the bridge mode, it is entirely in order to solve the shortcomings inherited proposed design patterns. In this mode, it can not achieve the abstract constraint, no longer bound to a fixed level of abstraction.
  • Excellent scalability: a look at our example, wants to increase to achieve? no problem! Want to increase the abstract, no problem! As long as the interface layer of external exposure allows such changes, we have to minimize the possibility of change.
  • Transparent implementation details to the customer: customers do not care about the details of the realization, it has completed the package via the aggregation layer of abstraction.

5, application scenarios

  • Does not apply or do not want to use inheritance scenario: not applicable or do not want to use inheritance scenarios such as inheritance hierarchy transition, not a more refined design particles scenario, consider using bridge mode.
  • Interface or abstract class unstable scenario: You know that the interface is unstable want to achieve business needs by implementing or inheritance, it is worth the candle, and it is the comparison fails approach.
  • Higher reuse scenario requirements: the fine particles of the design, the greater the possibility were reused, while the use of inheritance is restricted by the parent class, too fine granularity impossible.

6 Notes

Bridge model is very simple, the main consideration when using this mode to achieve and how to split the abstract, not involving a succession should consider using this mode, it also inherits doing it? It is intended to bridge mode or the change of the package, the package as far as possible factors that may change the finest minimum logical unit, to avoid the risk of proliferation. Therefore we during system design, inheritance discovered class of N layer, consider using bridge mode.

7 Best Practices

Inheritance feature class has many advantages, it has no disadvantages?

Strong invasion, there is a method of the parent class, subclass must also have this method. This is not selectable, can cause problems scalability.

Here is a simple example to illustrate: Father class has a method A, Son inherited this method, then GrandSon also inherited this method, the problem is suddenly one day Son To override this method of the parent class, he dare to do it? Absolutely not! GrandSon use the method inherited from the Father over A, if you modified, it would have to modify the relationship between the Son and GrandSon, that the risk is too great!

Bridge mode is the solution to this problem, the bridge pattern describes a weak relationship between classes. Continuing the above example, Father class can put methods may change put out, Son subclasses to have this method is very simple, bridges ride in the past, access to this method, GrandSon too, even if you Son subclass not want to use this method also it does not matter, does not have an impact on GrandSon, it is not inherited methods from the Son!

Can not say a bad inheritance, it is very good, but there are shortcomings, we can avoid weaknesses, to more clearly does not change, it is done by inheritance; if it can not determine whether changes occur, it is considered to be change, then be solved by bridge mode, this is a perfect world.

 

Reference: "Zen Design Patterns"

Published 95 original articles · won praise 16 · views 50000 +

Guess you like

Origin blog.csdn.net/tiankong_12345/article/details/102487638