Java design pattern – bridge pattern theory code combination

This is the 10th day of my participation in the August More Text Challenge

The bridge pattern follows the Java design pattern-decorator pattern, so if you’re interested, take a look.

Will be a review ya, will not come to see it together.

Like a sentence: “eight hours for life, eight hours for development”.

If you like it, let’s stick to it!!

‘😁

In the corner of the campus

Design Mode series:

• Java Design pattern – singleton pattern
• Java Design Pattern – Factory Pattern (1) Simple Factory pattern
• Java Design Pattern – Factory Pattern (2) Factory method pattern
• Java Design Pattern – Factory Pattern (3) Abstract Factory pattern
• Java Design pattern – Builder pattern
• Java Design pattern – Proxy pattern
• Java Design pattern – Adapter pattern
• Java Design pattern – Decorator pattern
• Java Design pattern – Bridge pattern
• Java Design pattern – Appearance pattern
• Java Design pattern – Composite pattern
• Java Design pattern – Share meta pattern
• Java Design Pattern – Template method pattern
• Java Design pattern – Policy pattern
• Java Design pattern – Chain of Responsibility pattern
• Java Design Pattern – The Mediator pattern
• Java Design Pattern – Observer Pattern (publish/subscribe pattern)
• Continuously updated…

I. Introduction of bridge mode

1) the introduction of

In real life, some classes have two or more dimensional variations, such as graphics that can be divided by shape or color. How do you design software like Photoshop that can draw shapes and colors? If using inheritance mode, m shapes and N colors of the graph will have M × N, not only corresponding to a lot of subclasses, but also difficult to expand.

In software systems, some types have two or more dimensional variations due to their own logic, so how to deal with this “multidimensional variation”? How can object-oriented techniques be used to make it easy to vary the type in multiple directions without introducing additional complexity? This uses the Bridge pattern. (Not limited to bridge mode, of course)

2) overview

Bridge pattern: Separate the abstract parts from the implementation parts so that they can vary independently. It is realized by using combinatorial relation instead of inheritance relation, thus reducing the coupling degree of abstraction and realization of these two variable dimensions.

Bridge mode transforms the inheritance relationship into association relationship, which reduces the coupling degree between classes, reduces the number of classes in the system, and also reduces the amount of code.

Separating the abstract part from its implementation is not a simple sentence. It is not separating the abstract class from its derived class, but rather the object that the abstract class and its derived class use to implement themselves. That still doesn’t make sense. Let’s first understand what abstraction is, what realization is, and what decoupling is.

Abstraction: The common conceptual relationship that exists in multiple entities is abstraction. Abstraction, as a process, involves ignoring information and treating different entities as if they were the same.

Realization: The concrete implementation given by abstraction is realization

Decoupling: Coupling is a strong correlation between the behaviors of two entities. And to remove their strong association is the release of coupling, or decoupling. Decoupling here refers to the decoupling of the coupling between abstraction and realization, or the transformation of their strong relationship into a weak one.

To change the inheritance relationship between two roles to an aggregation relationship is to change the strong relationship between them to a weak relationship. Decoupling in the bridge pattern, therefore, refers to the use of composition/aggregation rather than inheritance relationships between the abstraction and realization of a software system, so that the two can change relatively independently. That’s what the bridge model is about.

3) Pattern structure

Abstract hierarchy consisting of abstract characters and modified abstract characters.

An implementation hierarchy consisting of an implementation role and two concrete implementation roles.

Abstraction character: Abstracts the definition given and saves a reference to the implemented object.

Refined Abstraction: Extends Abstraction, changes and fixes the Abstraction definition of the parent class.

Implementor Role: This role provides the interface that implements the role, but does not provide the implementation. It is important to note that this interface is not necessarily the same as the interface definition for the abstract role; in fact, the two interfaces can be quite different. The implementation role should only give the low-level operations, while the abstract role should only give the higher-level operations based on the low-level operations.

Concrete Implementor Role: This role gives a Concrete implementation of the interface that implements the role.

4) Usage scenarios

• Scenarios where inheritance is not desired or applicable
• Scenarios where interfaces or abstract classes are unstable
• Scenarios with high reusability requirements

Two, bridge mode cases

2.1, case

Here’s an example:

You need to develop a cross-platform video player that can play video files in various formats on different operating system platforms (such as Windows, Mac, and Linux). Common video formats include RMVB, AVI, and WMV.

The player contains two dimensions suitable for bridging mode. The core intent of the bridging pattern is to isolate these implementations and allow them to vary independently, so that changes in each implementation do not affect the other implementations, thus coping with changes.

Illustration:

As you can see from the picture above,

The two dimensions are as follows:

1. OperatingSystemIt’s abstracting characters,Windows and MacIt’s an extended role,
2. VideoFileIs to implement roles,AVIFile and RMVBFileIt is to concretize the role.

I understand, or see the following 👇 code implementation is how it 😁

2.2 code implementation

OperatingSystem:

public abstract class OperatingSystemVersion {

    protected VideoFile videoFile;

    public OperatingSystemVersion(VideoFile videoFile) {
        this.videoFile = videoFile;
    }

    public abstract void play(String fileName);
}
Copy the code

Windows and Mac are extended roles

public class Windows extends OperatingSystemVersion {

    public Windows(VideoFile videoFile) {
        super(videoFile);
    }

    public void play(String fileName) {
        System.out.println("Windows is playing:"); videoFile.decode(fileName); }}public class Mac extends OperatingSystemVersion {

    public Mac(VideoFile videoFile) {
        super(videoFile);
    }

    @Override
    public void play(String fileName) {
        System.out.println("Mac is playing:"); videoFile.decode(fileName); }}Copy the code

VideoFile

public interface VideoFile {
    void decode(String fileName);
}
Copy the code

AVIFile and RMVBFile are concrete implementation roles

public class REVBBFile implements VideoFile {

    public void decode(String fileName) {
        System.out.println("RMVB file:"+ fileName); }}public class AVIFile implements VideoFile {
    @Override
    public void decode(String fileName) {
        System.out.println("Avi Video File:+ fileName); }}Copy the code

Testing:

public class Client {
    public static void main(String[] args) {
        OperatingSystemVersion os = new Mac(new AVIFile());
        os.play("War Wolf 3");
        /** * Output: Mac is playing: AVI Video file: Wolf Warrior 3 */}}Copy the code

After this writing, whether to extend OperatingSystem or VideoFile aspects, can be independently extended, very convenient. It also fits the definition of the bridge pattern in 👆 above: separate the abstract parts from the implementation parts so that they can vary independently. It is realized by using combinatorial relation instead of inheritance relation, thus reducing the coupling degree of abstraction and realization of these two variable dimensions.

Third, summary

The advantages and disadvantages:

The advantages of the Bridge mode are:

• Abstraction and implementation separation, strong ability to expand
• In line with the open and close principle
• In line with the principle of composite reuse
• The implementation details are transparent to the customer

The disadvantage is that since the aggregation relationship is established at the abstraction level, developers are required to design and program for abstraction, and can correctly identify the two dimensions of independent change in the system, which increases the difficulty of understanding and designing the system.

Matters needing attention

• Do not think about this pattern when it comes to inheritance, and encapsulate the changing factors into the smallest logical unit possible to avoid risk diffusion
• Consider using this pattern when you find that a class has n levels of inheritance

4. Talk to yourself

You roll me roll, everyone roll, when this road is the end ah. 😇 (or directly to heaven)

Sometimes I want to stop and have a rest. It’s hard to stick to one thing all the time. 😁

Hi, if you happen to read this article and think it’s good for you, give it a thumbs up and let me feel the joy of sharing, Crab. 🤗

If there is something wrong, please don’t add to it!!

Similarly, if there is any doubt, please leave a message or private message, we will reply to you in the first time.

Ongoing update