This is the sixth day of my participation in the August Text Challenge.More challenges in August

define

Bridge Pattern, also known as Bridge Pattern, is a kind of structural design Pattern, which is relatively difficult to understand. Bridging, as the name suggests, is used to connect two parts, bridging the separated abstract part and the implementation part.

The official word is to separate the abstract from its implementation so that they can all change independently.

There is another way to think about it: a class has two (or more) dimensions that vary independently, and we combine them so that they can be extended independently.

Applicable scenarios:

  • If a system needs to add more flexibility between the constructed abstract roles and the embodied roles, avoiding the static inheritance relationship between the two levels, they can be made to establish an association relationship at the abstraction level through the bridge pattern.

  • Systems that do not want to use inheritance or have a large increase in the number of system classes because of multi-level inheritance;

  • A class has two dimensions that vary independently, and both dimensions need to be extended.

UML class diagrams

Looking at the UML class diagram above, we can see that the bridging pattern is divided into the following four roles:

  1. Abstract: Defines an Abstract interface that has an object reference of type Implementor
  2. RefinedAbstraction: Extends the interface definition in Abstraction
  3. Implementor: an implementation part, which can be an interface or an abstract class. Its methods need not be the same as those in the abstract part. Generally, the implementation part provides the basic operations, while the abstract part defines the business methods based on the basic operations in the implementation part
  4. ConcreteImplementorA and ConcreteImplementorB: Implements the Implementor interface

Based on these roles, we can write common code for bridging patterns.

Generic code

The first is to implement part of the code:

Implementor.java

public interface Implementor {
    void operationImpl(a);
}
Copy the code

ConcreteImplementorA.java

public class ConcreteImplementorA implements Implementor{
    @Override
    public void operationImpl(a) {
        // Implement it}}Copy the code

ConcreteImplementorB.java

Public Class ConcreteImplementorB implements Implementor {@override public void operationImpl() {// Implementorb implements Implementor {@override public void operationImpl() {Copy the code

Then the code for the abstract part: Abstraction. Java

public abstract class Abstraction {
    private Implementor implementor;

    public Abstraction(Implementor implementor) {
        this.implementor = implementor;
    }

    public void operation(a) { implementor.operationImpl(); }}Copy the code

RefinedAbstraction.java

public class RefinedAbstraction extends Abstraction{

    public RefinedAbstraction(Implementor implementor) {
        super(implementor);
    }

    @Override
    public void operation(a) {
        // Extend the operation() method in Abstraction}}Copy the code

use

public class Test {
    public static void main(String[] args) {
        Implementor concreteImplementorA = new ConcreteImplementorA();
        Abstraction refinedAbstraction = newRefinedAbstraction(concreteImplementorA); refinedAbstraction.operation(); }}Copy the code

After looking at the generic code implementation above, I believe you have a good idea of the bridge pattern implementation structure.

Of course the generic code above is only the most commonly used implementation, there could be other scenarios such as RefinedAbstraction class which could be multiple depending on the actual situation. The ConcreteImplementor class may also have one or more.

With the above generic code, we can apply the above generic code structure as needed. Let’s look at an example.

The instance

Suppose we have a brush that can draw squares, rectangles and circles. Now we need to color these shapes. There are three colors: white, gray and black. Here we can draw 3*3=9 shapes: white square, white rectangle, white circle…

At this point, we can abstract out the graphics and colors, and combine the colors and shapes according to actual needs.

For such an implementation, we can call itThe bridge model.

UML class diagrams

By analogy with the general class diagram, we can get the following concrete class diagram:

Code implementation

Shape class hierarchy. Java

public abstract class Shape {
    Color color;

    public void setColor(Color color) {
        this.color = color;
    }

    public abstract void draw(a);
}
Copy the code

Rectangle. Java, Rectangle. Java, Rectangle

public class Circle extends Shape {
    @Override
    public void draw(a) {
        color.bepaint("Square"); }}public class Rectangle extends Shape {
    @Override
    public void draw(a) {
        color.bepaint("Rectangle"); }}public class Square extends Shape {
    @Override
    public void draw(a) {
        color.bepaint("Square"); }}Copy the code

Color interface color.java

public interface Color {
    void bepaint(String shape);
}
Copy the code

Three colors White. Java, Gray. Java, Black

public class White implements Color {
    @Override
    public void bepaint(String shape) {
        System.out.println("White"+ shape); }}public class Gray implements Color {
    @Override
    public void bepaint(String shape) {
        System.out.println("Grey"+ shape); }}public class Black implements Color {
    @Override
    public void bepaint(String shape) {
        System.out.println("Black"+ shape); }}Copy the code

Test Test. Java

public class Test {
    public static void main(String[] args) {
        / / white
        Color white = new White();
        / / square
        Shape square = new Square();
        // White square
        square.setColor(white);
        square.draw();

        / / rectangle
        Shape rectange = newRectangle(); rectange.setColor(white); rectange.draw(); }}Copy the code

Running results:

White square white rectangle

The above case from www.cnblogs.com/chenssy/p/3…

conclusion

Definition of bridge pattern: Decouple abstraction and implementation so that they can vary independently. By “abstraction”, I don’t mean “abstract classes” or “interfaces”, but rather a set of abstracted “libraries” containing skeleton code, with the real business logic delegated to the “implementation” in the definition. The “implementation” in the definition is not “the implementation class of the interface”, but a set of independent “class library”. The “abstractions” and “implementations” are developed independently and assembled together through combinatorial relationships between objects.

The JDBC driver is a classic application of the bridge pattern. If we want to change MySQL database to Oracle database, we only need to change the database driver, a line of code can be implemented:

Will com. Mysql.. JDBC Driver for oracle.. JDBC Driver. OracleDriver.