Bridge
Bridge separates an abstraction from an implementation dimension so both can vary independently. It is planned as part of the design rather than added only to reconcile an existing mismatch.
What you’ll understand
- Bridge separates an abstraction from an implementation dimension so both can vary independently. It is planned as part of the design rather than added only to reconcile an existing mismatch.
- Notification formats its semantic message and delegates transport to a composed Channel.
- Evaluate the tradeoff: Two hierarchies add indirection. If there is only one stable dimension of variation, a simpler strategy or function may be enough.
Useful first: Classes and Objects
The idea and when to recognize it
Bridge separates an abstraction from an implementation dimension so both can vary independently. It is planned as part of the design rather than added only to reconcile an existing mismatch.
- Requirement: A notification has a severity and a delivery channel. Both dimensions can vary.
- Change to anticipate: Send warning notifications through email and SMS without adding a subclass for every severity-channel pair.
- Design goal: Notification formats its semantic message and delegates transport to a composed Channel.
Start with the concrete problem
A notification has a severity and a delivery channel. Both dimensions can vary.
Send warning notifications through email and SMS without adding a subclass for every severity-channel pair.
| Direct implementation | Revised design |
|---|---|
| Hard-coding email into notification formatting binds two independent dimensions together. | Notification formats its semantic message and delegates transport to a composed Channel. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Two hierarchies add indirection. If there is only one stable dimension of variation, a simpler strategy or function may be enough. |
Responsibilities and contracts
Notification formats its semantic message and delegates transport to a composed Channel.
- Notification: Owns severity-level behavior. Public operations: send(text)
- Channel: Owns transport behavior. Public operations: deliver(text)
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A remote control abstraction can vary independently from the television or radio device it controls.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Two hierarchies add indirection. If there is only one stable dimension of variation, a simpler strategy or function may be enough.
Common mistake: Hard-coding email into notification formatting binds two independent dimensions together.
- Explain the choice: Notification formats its semantic message and delegates transport to a composed Channel.
- Challenge your choice: Two hierarchies add indirection. If there is only one stable dimension of variation, a simpler strategy or function may be enough.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…