Bridge of design mode (bridging)

Bridge Definition:
The abstraction and behavior are separated, independent, but can be combined dynamically.

Why use?
Typically, when an abstract class or interface has more than one specific implementation (concrete subclass), the relationships between these concrete may have the following two types:
1. These specific implementations happen to be parallel, as in the previous example, piling, there are two concrete class: square piles and round piles; the piles on these two shapes are tied and there is no conceptual repetition, so we can just use inheritance.
2. In practical applications, it is often possible to have conceptual overlap between these multiple concrete classes. Then we need to separate the common parts of the abstract and the behavior, which is intended to be placed in an interface, and now we need to design two interfaces, respectively, to place abstractions and behaviors.
For example, a cup of coffee, for example, has a medium cup and a large cup of the points, but also with milk without milk. If the simple inheritance, the four specific implementation (medium cup with milk without milk) there is a concept overlap, because there is a medium cup with milk, there is also a medium cup without milk, if again in the Cup this layer to achieve two inheritance, it is clearly chaotic, very poor extensibility. Then we use bridge mode to implement it.

How is it implemented?
Take the coffee mentioned above as an example. We originally intended to design only an interface (abstract class), after using bridge mode, we need to separate the abstraction and behavior, the addition of milk and non-dairy belong to the behavior, we will abstract them into a specialized behavior interface.

First look at the interface code of the abstract section:

 Public Abstract class　　coffee{Coffeeimp Coffeeimp;  publicvoid  setcoffeeimp () {  this.　　Coffeeimp = coffeeimpsingleton.getthecoffeimp ();   public coffeeimp getcoffeeimp () {returnthis.　　Coffeeimp;}  Publicabstractvoid  pourcoffee ();}

Where Coffeeimp is a non-dairy behavior interface, see its code as follows:

 Public Abstract class coffeeimp{  publicabstractvoid  pourcoffeeimp ();}

Now that we have two abstract classes, we inherit them separately to implement the concrete class:

//Medium Cup Public classMediumcoffeeextendscoffee{ PublicMediumcoffee () {setcoffeeimp ();}  Public voidPourcoffee () {coffeeimp coffeeimp= This. Getcoffeeimp (); //we repeat the number of times to explain whether the cup or a large cup, repeat 2 times is the cup 　　　　  for(inti = 0; I < 2; i++) {coffeeimp.pourcoffeeimp (); }}}//Big Cup Public classSupersizecoffeeextendscoffee{ PublicSupersizecoffee () {setcoffeeimp ();}  Public voidPourcoffee () {coffeeimp coffeeimp= This. Getcoffeeimp (); //we repeat the number of times to explain whether the cup or a large cup, repeat 5 times is a big cup 　　　　  for(inti = 0; I < 5; i++) {coffeeimp.pourcoffeeimp (); }}}

The above is the specific implementation of the Cup and the Big Cup. The following is the inheritance of the behavior coffeeimp:

//Add Milk Public classMilkcoffeeimpextendscoffeeimp{Milkcoffeeimp () {} Public voidPourcoffeeimp () {System.out.println ("With the delicious milk."); }}//no milk . Public classFragrantcoffeeimpextendscoffeeimp{Fragrantcoffeeimp () {} Public voidPourcoffeeimp () {System.out.println ("Nothing to add, fragrance"); }}

The basic framework of bridge mode we've set it up, and don't forget that there is another sentence in the definition: dynamic combination, we can now drink at least four kinds of coffee:
1. Medium Cup plus milk
2. Medium Cup without milk
3. Large cup with milk
4. Big Cup without milk

To see how the dynamic combination, before using, we do a preparatory work, design a single-state class (Singleton) to hold the current coffeeimp:

 Public class　　coffeeimpsingleton{  privatestatic  coffeeimp coffeeimp;　　  public Coffeeimpsingleton (Coffeeimp coffeeimpin) {this. coffeeimp = Coffeeimpin;}　　 publicstatic  coffeeimp Getthecoffeeimp () {  return  coffeeimp; }}

See how the Medium cup plus milk and the big cup of milk come out:

// take out the milk . New Coffeeimpsingleton (new  milkcoffeeimp ()); // Medium cup plus milk New Mediumcoffee (); Mediumcoffee.pourcoffee (); // large cup with milk New Supersizecoffee (); Supersizecoffee.pourcoffee ();

Note: The execution classes of bridge mode, such as Coffeeimp and coffee, are one-to-one relationships, and the correct creation of COFFEEIMP is the key to the pattern.

Application of bridge mode in EJB
There is a data Access Object (DAO) pattern in the EJB, which separates the business logic from the specific data resources, because different databases have different database operations. The behavior of manipulating different databases is independently abstracted into a behavior interface DAO. as follows:
1.Business Object (similar to coffee)
Implement some abstract business operations: such as looking for a user under all orders
The database operations involved use Daoimplementor.
2.Data Access Object (similar to Coffeeimp)
Some abstract operations on database resources
3.DAOImplementor such as Orderdaocs, Orderdaooracle, Orderdaosybase (similar to Milkcoffeeimp fragrantcoffeeimp)
Specific database operations, such as the "INSERT into" statement, Orderdaooracle is the Oracle orderdaosybase is the Sybase database.
4. Database (Cloudscape, Oracle, or Sybase database via JDBC API)

Transferred from: http://www.jdon.com Banqiao

Bridge (bridging) of design mode (RPM)