Novice Java Design pattern-bridging mode from abstraction and implementation

Bridging mode, when beginners in fact very 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 need to know the ins and outs, so, very quickly I have been interested in this naming, 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 have based on the interpretation of the dictionary.

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

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

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

The abstract is the interface, which implements the class.

In our code, we sometimes pass in 2 types of parameters when we pass in the object's parameters instead of the base data type parameters. Example

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 method, you can pass in the number of ArrayList and LinkedList, but call another method you can only pass in ArrayList, This is obviously flawed, and when ArrayList does not meet our needs, we will need to rewrite a method1 method, which is very detrimental to our code structure and violates the open and closed principles 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 a demand 2, then you need to change the place is much more ...

What must be done, 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 the TestInterfaceImpl2 object, modify the original code is the last thing we want to see, of course, you can also add an adapter class to implement, but, Suppose our bridge design was not designed like this at the time, but the reference object of the incoming interface?

Change Bridge to

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

This way, you don't need to modify 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 abstract interface and implementation of the partial separation, the incoming reference to the class object, so that your implementation of the class can be changed for the entire code will not have no matter what effect ....

This is the bridging mode!

Object-oriented, it's not easy!

Novice Java Design pattern-bridging mode from abstraction and implementation