Meaning of abstraction in bridge design pattern

Question

I am confused on how should I explain the bridge design pattern in java. Based on GoF's definition:

The bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently.

However, I thought that we do abstractions (use of abstract classes and interfaces) to decouple the implementation from the rest of the code (since we are just declaring interfaces or abstract classes instead of the implementing class). Now, I think I am wrong on how I understood abstraction because of the bridge pattern.

What exactly is abstraction and how is it decoupled from implementation in the bridge pattern?

Answer 1

I thought that we do abstractions (use of abstract classes and interfaces) to decouple the implementation from the rest of the code

Your understanding is correct.
You use the bridge in corner cases where you have not only one but two (or more) abstractions that you don't want to mix together.

The GOF pattern illustrates that very well.
A window for a toolkit relies on two abstractions :

• the window in terms components (icon, transient, fullsize, etc...)
• the window in term of OS implementation/features.

If you define a single interface : Window, you willl couple the two abstractions into a same interface and Window implementations will so couple them consequently.

If you define two interfaces : Window (as a model/functional concept) and WindowImp (as an OS implementation) and two distinct hierarchies : you decouple the abstractions.