Bridge Pattern
Category Programming Techniques
When I started learning Java, the teacher always liked to use an example to explain inheritance, which was drawing. Here we have a brush that can draw squares, rectangles, and circles (everyone knows how to do this, so I won't explain it). But now we need to color these shapes, and there are three colors available: white, gray, and black. Here we can draw 3*3=9 shapes: white square, white rectangle, white circle, etc. ... At this point, we almost know there are two solutions:
Solution one: Provide versions of each shape in various colors.
Solution two: Combine colors and shapes according to actual needs.
If we implement solution one, can we also understand it like this? Provide versions of each color for various shapes? This is completely possible. For example:
For the two shapes, we will be very clear about this issue: if we add an ellipse, do we need to add three more colors? Suppose we add green, we will need to add four shapes, continue to add, continue to add... Each addition will increase the number of classes (if you add a color, it will increase the number of classes by the number of shapes, if you add a shape, it will increase the number of classes by the number of colors), I think no programmer would want such a situation! Then let's look at solution two.
The solution provided by solution two is to provide two parent classes, one for color and one for shape. Both the color parent class and the shape parent class contain the corresponding subclasses, and then combine colors and shapes according to needs.
For several dimensions of change, we generally use solution two to implement it, which not only reduces the number of classes in the system but also facilitates system expansion. The application of solution two is called the bridge pattern.
I. Pattern Definition
The bridge pattern separates the abstract part from its implementation part, allowing them to change independently.
The bridge pattern transforms the inheritance relationship into an association relationship, reducing the coupling between classes, reducing the number of classes in the system, and also reducing the amount of code.
The phrase "separating the abstract part from its implementation part" is not very easy to understand. In fact, it is not about separating the abstract class from its derived class, but about the abstract class and its derived class using objects to implement themselves. If you still can't understand this, let's first clarify what is abstraction, what is implementation, and what is decoupling.
Abstraction: The concept is the action or process of extracting one or several characteristics of a complex object while ignoring other characteristics. In object-oriented programming, it is the process of extracting common properties of objects to form a class.
Implementation: A specific implementation for abstraction. It is the reverse process of abstraction, and implementation is a further concretization of abstract things.
Decoupling: Decoupling is to release the coupling between abstraction and implementation, or to change the strong association between them into a weak association, changing the inheritance relationship between the two roles into an association relationship.
For that sentence: separating the abstract part from its implementation part, in "Design Patterns in Plain English," it means that the system may have multiple perspectives for classification, and each perspective may change. So, separating these multiple perspectives and letting them change independently reduces their coupling.
The so-called decoupling in the bridge pattern refers to using an association relationship (composition or aggregation relationship) instead of an inheritance relationship between the abstraction and implementation of a software system, so that the two can change relatively independently, which is the purpose of the bridge pattern.
II. Pattern Structure
The following is the UML structure diagram of the bridge pattern:
The bridge pattern mainly includes the following roles:
Abstraction: Abstract class.
RefinedAbstraction: Expanded abstract class.
Implementor: Implementation class interface.
ConcreteImplementor: Concrete implementation class.
III. Pattern Implementation
The pattern scenario we will use is drawing. The UML structure diagram is as follows:
Example
public abstract class Shape {
Color color;
public void setColor(Color color) {
this.color = color;
}
public abstract void draw();
}
Then there are three shapes.
Circle Circle.java:
public class Circle extends Shape{
public void draw() {
color.bepaint("Circle");
}
}
Rectangle Rectangle.java:
public class Rectangle extends Shape{
public void draw() {
color.bepaint("Rectangle");
}
}
Square Square.java:
public class Square extends Shape{
public void draw() {
color.bepaint("Square");
}
}
Color interface Color.java:
```java public interface