CODEWITHSUNDEEP
design-patterns
Chandan
Chandan

Reputation: 1504

Bridge pattern understanding

I understand bridge pattern to some extent. I understand the decoupling of the interface and implementation. It uses an implementor class like a plugin which holds the actual logic of the derived class implementation.

But can some one explain how it allows the interface and derived to evolve independently? If I want to add a new method to the interface, it will have to be implemented in the derived class which will modify it.

Secondly, the client code has to be modified to set the new implementor when new object is needed.

Upvotes: 8

Views: 3189

Answers (2)

Claudio
Claudio

Reputation: 10947

Yes, the intent of the Bridge patter is to decouple abstraction (i.e., interface) from implementation, to let them vary independently. In practice, the idea is to use two separate hierarchies instead of the classic single hierarchy.

Let's make an example. Suppose that you have a Window abstraction, and you need to create an IconWindow subclass that specializes Window for every supported platform.

With a single hierarchy, you get:

                     Window
                       |--------------...
                   IconWindow
                       |
   -----------------------------------------------...
   |                   |                   |
XIconWindow       MSIconWindow      OSXIconWindow

This structure is very unconvenient, because:

  • if you want to add a new subclass that specializes Window (e.g., BitmapWindow) you must create a subclass for each supported platform (i.e., three subclasses in this example).

  • If you want to add a supported platform, you must add a new subclass for each existing specialization.

Therefore, it is better to decouple the two hierarchies by having:

             imp
      Window--------------------------> WindowImp
         |                                  |
    -----------....            ---------------------------------
    |                          |              |                |
IconWindow                XWindowImp      MSWindowImp    OSXWindowImp

Window and WindowImp are interfaces. IconWindow uses methods provided by Window. Window, in turn, calls the related method on imp.

The relationship between Window and WindowImp is called a Bridge.

Example: IconWindow::DrawBorder() uses Window::DrawRect(), which calls imp->DevDrawLine() which is declared in WindowImp and defined in the concrete subclasses (e.g., in class XWindowImp).

My suggestion is to read the book: Design patterns - Elements of Reusable Object-Oriented Software" (http://en.wikipedia.org/wiki/Design_Patterns) that contains the example above.

Upvotes: 22

Atul
Atul

Reputation: 1774

I think Java JDBC API is the best example to illustrate the user of Bridge Design Pattern. The client uses the abstraction(JDBC API) without worrying about the implementation (MYSQL, Oracle etc) that different SQL vendors provide.

To illustrate further consider that you have EmployeeDAOImpl that implements EmployeeDAO interface with save,update,delete methods. Now, this EmployeeDAOImpl will use the JDBC API (Abstraction) to perform the CRUD operations without worrying about the database used. The only thing that EmployeeDAOImpl need is the url to load the driver.

Now the crux is, the hierarchy of EmployeeDAOImpl and other DAO can vary independently. They don't have to worry about the implementation of the abstractions of JDBI API.

Upvotes: 3

Related Questions