Java design mode-bridging mode

This article describes the concept of bridging (bridge) mode in design mode, usage, and how to use bridging mode for development in practical applications.

The concept of bridge mode

Bridge mode is one of the structural design patterns. Bridge mode is based on the minimal design principle of the class, and allows different classes to assume different responsibilities by using behaviors such as encapsulation, aggregation, and inheritance. Its main feature is to separate the abstraction (abstraction) from the Behavior implementation (implementation), so that the independence of each part can be maintained and the function extension should be addressed.

Application Scenarios for Bridge mode

Object-oriented Programming (OOP) has the concept of class inheritance (subclass inheriting parent Class), if a class or interface has more than one specific implementation subclass, if these subclasses have the following attributes:
-There is a sub-class attribute with relative juxtaposition.
-There is a conceptual crossover.
-Variability.
We can use bridge mode to abstract and concrete, and reconstruct related classes.

To make it easy to understand, let's say, for example, the car Class (cars), suppose there are 2 subcategories, Truck Class (Truck) and bus Class (bus), they have [set engine] This action behavior, through the different engine specification settings, you can set them to such as 1500cc (Car1500) , and 2000cc (Car2000) of the car.
So, whether it's a 1500cc truck or a 2000cc truck, or a 1500cc bus or a 2000cc bus, they can be subcategories of cars, and:
-There is a sub-class attribute with relative juxtaposition. The type of car, with the car engine specification is a 2-side property of the car, without conceptual duplication.
-There is a conceptual crossover. Both the truck and the bus have 1500cc and 2000cc engine specs.
-Variability. In addition to trucks and buses, there may also be fire engines, and in addition to cars with 1500cc and 2000cc engine specs, there may be 2500cc cars and so on.

So, how do we design the car class?

Method One

All possible subclasses are designed through inheritance. Maybe we'll think of the following inheritance relationship:
General Category: Car
Automotive sub-categories by Category: Bus,truck
Automotive sub-category by engine: bus1500,bus2000,truck1500,truck2000
This action of setting up the engine is implemented by each sub-class.

But if you need to add a fire truck (Firecar) Later, and add an engine specification of 2500cc, the subclass that needs to be implemented will be:
Bus1500,bus2000,bus2500,truck1500,truck2000,truck2500,firecar1500,firecar2000,firecar2500 of up to 9.
In other words, this design method, the number of subclasses will increase with the geometric progression.
Also, the engine settings of the bus1500,truck1500 are the same, they should be the same, but now it is difficult to avoid repetitive action behavior by dividing them into different subclasses.

Method Two

Ways to set up different engines for bus and truck, respectively
General Category: Car
Car sub-Category: Bus,truck

Then, in the bus class, we provide 1500cc and 2000cc engine Setup methods respectively:
Bus extends Car {
public setengine1500cc ();
public setengine2000cc ();
}

The 1500cc and 2000cc engine Setup methods are also available in the Truck class, respectively:
Truck extends Car {
public setengine1500cc ();
public setengine2000cc ();
}

In this case, the number of subclasses is controlled. But on the one hand, if each additional engine specification needs to be modified for all car subclasses, on the other hand, even if the engine is set to behave the same, different car subclasses need to provide the exact same method.

In the actual application development, the above 2 kinds of methods will cause to move the whole body, and there will be a lot of duplicate code.

Bridge mode can be a good solution to this kind of problem.

Client
Users of Bridge mode
Abstraction
Abstract class interface (interface or abstract class)
Maintain a reference to the behavior implementation (Implementor)
Refined Abstraction
Abstraction sub-class
Implementor
Behavior implementation class Interface (abstraction interface defines a higher level of operation based on the Implementor interface)
Concreteimplementor
Implementor sub-class

Application example of bridge mode

Let's see how to use Bridge mode to design a car class.

Abstract-Abstraction class: Automotive class and its subclasses:
Car: General Category
Truck: Automobile sub-class-Truck class.
Bus: Car sub-class-bus.

Behavior Realization-Implementor: The Behavior class and subclass of automobile engine setting
Setcarengine: Setup interface for automotive engines
setcarengine1500cc: Setting up the 1500cc engine
setcarengine2000cc: Setting up the 2000cc engine

Code:

Package Zieckey.designpatterns.study.bridge;

Test

public class Client
{
public static void Main (string[] argv)
{
Engine engine1500 = new engine1500cc ();
Engine engine2200 = new engine2200cc ();

Vehicle bus1500 = new Bus (engine1500);
Vehicle bus2200 = new Bus (engine2200);
Bus1500.setengine ();
Bus2200.setengine ();

Vehicle truck1500 = new Truck (engine1500);
Vehicle truck2200 = new Truck (engine2200);
Truck1500.setengine ();
Truck2200.setengine ();
}
}

Package Zieckey.designpatterns.study.bridge;

/**
 *
 * Auto Class (Vehicle), assuming there are 2 subcategories, Truck Class (Truck) and bus Class (bus),
 * they have [set engine] This action behavior, through different engine specification settings, The
 * can set them to cars such as 1500cc (Car1500), and 2000cc (Car2000).
 * So, whether it's a 1500cc truck or a 2000cc truck, or a 1500cc bus or a 2000cc bus, they can be subcategories of cars, and:
 *     -There are sub-class properties that are relatively parallel. The type of car, with the car engine specification is a 2-side property of the car, without conceptual duplication.
 *    -There is a conceptual crossover. Both the truck and the bus have 1500cc and 2000cc engine specs.
 *    -variability. In addition to trucks and buses, there may also be fire engines, and in addition to cars with 1500cc and 2000cc engine specs, there may be 2500cc cars and so on.
 *
 * @author
 * @since 2008/06/23
 */
Public abstract class Vehicle
{
    private engine engine;

Vehicle (Engine engine)
{
This.setengine (engine);
}

public abstract void Setengine ();

public void Setengine (engine engine)
{
This.engine = engine;
}

Public Engine Getengine ()
{
return engine;
}
}

Package Zieckey.designpatterns.study.bridge;

Abstraction sub-class: This is a subclass of the automotive abstract class

public class Bus extends Vehicle
{
Public Bus (Engine engine)
{
Super (engine);
}

@Override
public void Setengine ()
{
System.out.print ("Set Bus Engine:");
Getengine (). Setengine ();
}
}

Package Zieckey.designpatterns.study.bridge;

Abstraction sub-class: This is a subclass of the automotive abstract class

public class Truck extends Vehicle
{
Public Truck (Engine engine)
{
Super (engine);
}

@Override
public void Setengine ()
{
System.out.print ("Set Truck Engine:");
Getengine (). Setengine ();
}

}

Package Zieckey.designpatterns.study.bridge;

Behavior interface of Automobile class

public interface Engine
{
public void Setengine ();
}

Package Zieckey.designpatterns.study.bridge;

/** Concreteimplementor */
Behavior Implementation Subclass

public class engine2200cc implements Engine
{

public void Setengine ()
{
System.out.println ("Engine 2200CC");
}

}

Package Zieckey.designpatterns.study.bridge;

/** Concreteimplementor */
Behavior Implementation Subclass

public class engine1500cc implements Engine
{

public void Setengine ()
{
System.out.println ("Engine 1500CC");
}

}

Summary: Bridge mode is a pattern of abstraction separated from its implementation. It is mainly applied to: When a thing is a set of changes, and the operation of these things (implementation) is also a set of changes in the situation, that is, they are changeable.

Java design mode-bridging mode