Does the Bridge Pattern decouples an abstraction from implementation?

Question

I learned Bridge pattern from different articles and I have implemented that as per my understanding . One thing that is confusing me is bridge pattern says

BridgePattern decouples an abstraction from its implementation so that the two can vary independently

what is meaning of this statement? Is implementation resides at in separate jar ?

what is meaning of vary independently statement ?

considering the provided journaldev article, elaborate the answer.

Any help is greatly appreciated.

Answer 1

BridgePattern decouples an abstraction from its implementation.

Abstraction and Implementation can vary independently since the concrete class does not directly implement Abstraction ( interface)

Key note: Two orthogonal class hierarchies (The Abstraction hierarchy and Implementation hierarchy) are linked using composition (and not inheritance).This composition helps both hierarchies to vary independently.

Implementation never refers Abstraction. Abstraction contains Implementation interface as a member (through composition).

Coming back to your question regarding the example code in journaldev article :

Shape is Abstraction

Triangle is RedefinedAbstraction

Color is Implementor

RedColor is ConcreteImplementor

A concrete Shape object : Triangle extends Shape but does not implement the Color interface.

public class Triangle extends Shape{
}

RedColor and GreenColor actually implement the Color interface.

The Concrete Shape object (Triangle) is independent of implementing abstraction (i.e. Color interface).

Shape tri = new Triangle(new RedColor());

Here Triangle contains a concrete Color object ( Composition). If there is a change in the Color abstraction (interface), RedColor and GreenColor are responsible for implementing the abstraction of Color interface.

Shapes like Triangle is not affected by changes in contract to the Color interface. So the Color interface can vary independently. This is possible because Shape holds the contract that uses Composition rather than implementation.

In Summary,

1. Bridge is a structural pattern
2. Abstraction and implementation are not bound at compile time
3. Abstraction and implementation - both can vary without impact in client

Use the Bridge pattern when:

1. You want run-time binding of the implementation,
2. You have a proliferation of classes from a coupled interface and numerous implementations,
3. You want to share an implementation among multiple objects,
4. You need to map orthogonal class hierarchies.

Useful links:

tutorialspoint artice

dzone article

oodesign article

sourcemaking article

Related post:

When do you use the Bridge Pattern? How is it different from Adapter pattern?

Answer 2

This statement simply means, that you can switch implementor, to which abstraction points to, in run-time and everything should work (like in Strategy Pattern; but in Strategy Pattern, only strategies are abstract). It can be also understood as separating two classes, so that they don't have to know about each other more than just their interfaces.

Answer 3

For me Bridge is not really the most foremost DP in the GOF bible, since it is mostly a derivative of Strategy. As some other patterns that have not aged so well (factory method?) it implies more inheritance with abstract classes holding behavior than other patterns, hence is less generally applicable.

It's mostly Strategy doing the big work, but a major issue with Strategy is that the strategy often needs knowledge about its context.

In some languages this leads to strategies being declared friend of the context, or strategies defined as internal classes in Java.

This means that the context often ends up with knowledge of existence of the various concrete strategies. You can avoid this by using a setStrategy() function, but the reverse dependency from concrete strategy to context usually survives, due to efficiency reasons (you want to manipulate the context's data structures directly).

This issue is kind of solved by Bridge, as the context of Strategy is now abstract, but still a class a priori, since it has at least the code for Strategy. It should usually define an access API sufficient for the concrete Strategies to work with, possibly with holes i.e. abstract methods. You put an occurrence of AbstractContext in the signature of the operations on AbstractStragey and you're good.

So in my point of view, Bridge completes Strategy by making the Context concrete enough for the strategies to work, but still abstract enough that it can be orthogonally refined w.r.t. concrete strategies (with feedback effects when implementing abstract API of the context that the concrete strategies actually use).

A simpler way of seeing bridge is to say that the AbstractStrategy operations should always take abstractions as parameters rather than really knowing intimately their context.

To answer the OP question more precisely :

what is meaning of this statement? Is implementation resides at in separate jar ?

Yes, indeed, typically you could define the Abstraction and Implementor in a package "base" (tey could be interfaces). The concrete Implementors can each reside in a package "implXX". The concrete context can reside in separate packages "contXX". There are no cycles in the dependency graph, everybody depends on base, new "contXX" and "implXX" can be defined independently (no dependencies at all between them) thus the bold statement in the OP.

what is meaning of vary independently statement ?

Think of an editor plugin in eclipse; it must handle the actions on buttons and clicks (like a strategy), but the actual action the strategy needs to do is act on the editor state itself (e.g. "highlight text"). You define what an editor possesses in an abstract way, including the fact that it has Handler for clics and keypresses as well as highlighting and navigation features, even these can be overriden by concrete editors (flash instead of highlight). That's a bridge, you can define new editors and new handler independently.

With some dependency injection (e.g. Google guice) or some manual factory code or component orientation to cleanly setStrategy from outside you get very low coupling of the various parts of the application.

considering the provided journaldev article, elaborate the answer.

honestly I think this is a not the best application of the DP since the Color implementations don't seem to care much about their context. You should use a Decorator here as Color is an independent concern from Shape.

Have a look a at these slides for a solution with a Decorator (partly in French, sorry). https://www-licence.ufr-info-p6.jussieu.fr/lmd/licence/2015/ue/3I002-2016fev/cours/cours-9.pdf (slides 16-18) based on example introduced here : https://www-licence.ufr-info-p6.jussieu.fr/lmd/licence/2015/ue/3I002-2016fev/cours/cours-4.pdf slides 10 to 15.

On that example, we would need Bridge if "updateInertie" was member of Forme, which does not sound preposterous. Again Bridge emerges more as a combination of other patterns.