Novice Java Design pattern-bridging mode from abstraction and implementation

Bridging mode, when beginners really do not understand why this mode is named Bridging mode, the mind suddenly Lenovo. In fact, I study is a more painful thing, because I have to know the ins and outs in order to learn to go in, so soon I have a name for this interest, bridging?

Well, bridge it up! Change the bridge word to ligature first, connect? Bridging? The biggest difference between bridging and connecting is that bridging is a way of connecting two things that have the same pattern, which I can tell by the dictionary.

Well, with the same pattern, instantly think of the interface, is there an occupational disease?

Separate the abstractions from the implementation, so that they can be changed independently.
--"Design pattern" GOF

Combined with Gof's design pattern, it's easy to understand why it's named bridging.

The abstract is the interface, which implements the class.

In our code, we sometimes pass in 2 types of arguments when passing in an object parameter instead of a basic data type parameter. Like what

public void Menthd (List list)

public void Method1 (ArrayList ArrayList)

There is one of the biggest differences between the two, ArrayList is the implementation class of the List, when we call the methods method, you can pass in the arguments are ArrayList and LinkedList, but the second method to call you can only pass in ArrayList, This is obviously flawed, and when ArrayList doesn't meet our needs, we have to rewrite a method1 method, which is bad for our code structure and violates the open and closed principle of Java design.

Take out this we write the actual code, of course we no longer use ArrayList to do demo.

Define the interface first

Public interface TestInterface {public void method ();

One more implementation class.

public class TESTINTERFACEIMPL1 implements testinterface{@Overridepublic void method () {System.out.println ("requirement 1");}}

Call class:

public class Bridge {public void Test (TestInterfaceImpl1 impl1) {Impl1.method ()}}

Test code:

public class Test {public static void main (string[] args) {Bridge bridge = new Bridge (); TESTINTERFACEIMPL1 impl1 = new TestInterfaceImpl1 (); Bridge.test (IMPL1);}}

Output: Demand 1

Then, our demand changes, we want to change the method of testinterface in the implementation of another requirement 2, then you need to modify the place is more ...

What you have to do, add the implementation class.

public class TESTINTERFACEIMPL2 implements testinterface{@Overridepublic void method () {System.out.println ("Requirement 2");}}

Then we need to modify bridge, to add a method to pass in the TestInterfaceImpl2 object, change the original code is the last thing we want to see, of course, you can also add an adapter class to implement, but, What if our bridge design was not designed this way at the time, but the reference object of the incoming interface?

Modify Bridge to

public class Bridge {public void Test (TestInterface impl) {Impl1.method ()}}

This way, you don't have to change the original code when you have new requirements.

Test class:

public class Test {public static void main (string[] args) {Bridge bridge = new Bridge (); TestInterface impl1 = new TestInterfaceImpl1 (); Bridge.test (IMPL1); TestInterface impl2 = new TestInterfaceImpl2 (); Bridge.test (IMPL2);}}

Output:

Demand 1
Demand 2

This is what Gof said about separating the abstract from the implementation, so that they can be independently changed.

In this set of code, the abstract is the interface, the abstraction of the interface and implementation of the partial separation, the incoming reference to the class object, so that your implementation of the class and how to change the entire code will not have any effect ....

This is the bridging mode!

Object-oriented, it's not easy!

Novice Java Design pattern-bridging mode from abstraction and implementation