Bridge Pattern - benefit of compilation in Java?

Question

It is said in Design Patterns - Elements of Reusable Object-Oriented Software book :

In situations where there's only one implementation (one-to-one) ,creating an abstract implementor class isn't necessary.This is a degenerate case of the bridge pattern; there's a one-to-one relationship between Abstraction and Implementor.Nevertheless,this seperation is still useful when a change in the implementation of a class must not affect its existing clients- that is they shouldn't have to be recompiled,just relinked.

I doubt about the benefit of compile time because I can't imagine a case in Java where a change in implementation makes recompile its superclass (abstract in this case).

For example, if we have X extends Y and a client do :

Y y = new X();  

A change in X does not mean a recompilation of Y (of course if we don't want to change the method signatures of X)

It is exactly the same thing when using Bridge Pattern :

YAbstraction yabstraction = new YRefinedAbstraction(new XImplementor());

A change in XImplementor does not mean a recompilation of YAbstraction.

So, according to me, this benefit does not take place in Java and for a one-to-one => no Bridge Pattern needed.

Perhaps a change in a subclass force superclass to be recompiled in other languages ? like SmallTalk and C++ ?

What are your opinions ?

Answer 1

In the bridge pattern you have two class hierarchies: one for the Abstraction (e.g. Window with derived classes like DialogWindow and IconWindow) and one for the Implementor (e.g. WindowImpl with derived classes like XWindowImpl and PMWindowImpl). Implementor's interface should be hidden from the clients of the Abstraction. Normally, the Implementor provides low-level primitives and the Abstraction builds higher-level operations in terms of those primitives, thus in a well-layered system clients should have no need to see the low-level interface offered by the Implementor. If one day, it turns out that the interface offered by WindowImpl isn't general enough to accomodate new XYZWindowImpl, you retain the freedom to change it since WindowImpl should never be used directly by your clients but only by Window and its subclasses. Thus, the change in the interface of WindowImpl may require modifications to Window, but will not propagate to the clients. Also, one often hides the Implementor behind an Abstract Factory which is used to configure the bridge.

The advantage of the Bridge pattern you described depends on hiding of Implementor's interface from the clients of the Abstraction. In C++ you can easily hide Implementor's interface by simply not providing the header file. In Java you can make the Implementor an abstract class with package private members.

In C++ clients of the Abstraction will not need to be recompiled, only relinked. In Java, instead of linking you have class loading and thus all you need to do is reload the application with new settings and a new jar file.

Imagine for example a situation when a command line option or an environment variable is used by an Abstract Factory to configure the bridge with the right kind of ConcreteImplementor. In such case you simply need to reload the application with new command line/environment settings and a new jar file containing the new ConcreteImplementor. You can do this without recompiling client code.

Thus to provide direct answer to your question: also in Java the Bridge pattern does have the advantage described in the question. Possibly to even greater extent if you count the fact that no relinking ever takes place.