Bridging mode-a design pattern for earning money.

Objective:

Write n years of code, know that the design pattern has been 8, 9 years, using design patterns, there are some good use. But there are some design patterns that should not exist.

Start from here:

Bridging mode

1. Function:

Decoupling an abstraction from the implementation so that the two can change independently. (Excerpt from wiki)

2.UML

3. Code:

/**"Implementor"*/Interfacedrawingapi{ Public voidDrawcircle (DoubleXDoubleYDoubleradius);} /**"Concreteimplementor"*/classDrawingAPI1Implementsdrawingapi{ Public voidDrawcircle (DoubleXDoubleYDoubleradius) {System.out.printf ("Api1.circle at%f:%f radius%f\n", x, y, radius); }} /**"Concreteimplementor" 2/2*/classDrawingAPI2Implementsdrawingapi{ Public voidDrawcircle (DoubleXDoubleYDoubleradius) {System.out.printf ("Api2.circle at%f:%f radius%f\n", x, y, radius); }} /**"Abstraction"*/Interfaceshape{ Public voidDraw ();//Low-level    Public voidResizebypercentage (DoublePCT);//High-level} /**"Refined Abstraction"*/classCircleShapeImplementsshape{Private Doublex, y, radius; PrivateDrawingapi Drawingapi;  PublicCircleShape (DoubleXDoubleYDoubleradius, Drawingapi drawingapi) {        This. x = x; This. y = y; This. Radius =radius;  This. Drawingapi =Drawingapi; }    //low-level i.e. implementation specific    Public voidDraw () {drawingapi.drawcircle (x, y, radius); }      //high-level i.e. abstraction specific    Public voidResizebypercentage (Doublepct) {Radius*=pct; }} /**"Client"*/classBridgepattern { Public Static voidMain (string[] args) {shape[] shapes=NewShape[2]; shapes[0] =NewCircleShape (1, 2, 3,NewDrawingAPI1 ()); shapes[1] =NewCircleShape (5, 7, 11,NewDrawingAPI2 ());  for(Shape shape:shapes) {shape.resizebypercentage (2.5);       Shape.draw (); }   }}

4. Comments:

This pattern is for pattern, and there is a problem:

If the code is written like this, there will be a lesson called "refactoring" waiting for you, which is why you earn money. Let the computer experts earn away.

Shape already has a complete abstraction, drawapi have the necessary horses to exist? No. Don't see any use? There is no difference between writing in the draw method and writing in Drawapi.

In fact, similar and really useful examples are output to peripherals: such as drawing to the screen, pressure pen. But here's the basic principle: the screen and the pressure pen implement a set of the same painting API.

The draw of shape uses the drawing API to output to a real device.

That's where it really makes sense. Wait Why do I think we are here: tricky. Only the expansion of abstraction, has formed a new implementation. No appearance and function of the said, the two independent changes!!!

Decoupling an abstraction from the implementation so that the two can change independently?? Abstract there is no shred change, only the reality is changing. There is no slightest change in abstraction. Once this occurs. The abstraction has been changed to think of something. The abstraction is expanded to enhance the functionality. But implementation is still an abstract implementation.

(Is this not an appearance mode?) So where's the bridging mode? ）

Once the abstraction and implementation are decoupled, it means that they have different meanings. This is the time to refactor.

Bridging mode-a design pattern for earning money.