Bridge: Decoupling Abstraction
Split a large class into two independent hierarchies — abstraction and implementation — so both can evolve without affecting each other.
Why this matters
Inheritance is a strong coupling tool. When a class varies along two independent dimensions — say, type of remote control and type of device — modeling both in one hierarchy produces M × N subclasses. Bridge separates the two dimensions: the abstraction (RemoteControl) holds a reference to the implementation (Device) and delegates to it. Adding a new remote or a new device is a single new class, not N or M.
Composition over inheritance
Bridge is one of the clearest examples of favouring composition over inheritance. The remote has a device rather than being a kind of device. This lets you swap the device at runtime — pass a different implementation to the same abstraction constructor without touching any subclass. The same principle appears in JDBC (the SQL API is the abstraction; the driver is the implementation) and in graphics libraries that separate shape logic from rendering backends.
💡Key takeaway
If you have M abstractions × N implementations, Bridge prevents M×N classes by composing them — add new remotes or devices independently.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: If you have M abstractions × N implementations, Bridge prevents M×N classes by composing them — add new remotes or devices independently.
✗ Your version