Bridge Pattern vs. Adapter Pattern

Bridge and Adapter can look similar because both rely on composition and delegation. The difference is intent.

Adapter Fixes A Mismatch

Adapter says:

• the client contract is already fine
• one dependency exposes the wrong interface
• translate that dependency into the expected contract

Adapter is usually retrospective. Something already exists and does not fit.

Bridge Designs For Independent Variation

Bridge says:

• two dimensions of change are real
• one hierarchy should not encode both
• split abstraction from implementation deliberately

Bridge is usually proactive. It designs the variation boundary before subclass growth becomes unmanageable.

Practical Java Shortcut

Ask this:

• “Am I wrapping an awkward dependency?” -> Adapter
• “Am I separating two evolving dimensions?” -> Bridge

If the answer is the first one, do not build a bridge-shaped hierarchy just because it looks elegant.

Failure Mode

Teams sometimes misuse Bridge where a simple adapter would do. The result is an abstraction family no client really asked for. The opposite mistake also happens: teams keep writing adapter after adapter while the real problem is a hierarchy encoding multiple dimensions and needing a bridge.