The Bridge pattern fits scenarios where a system has two independent dimensions of variation — such as an abstraction and its underlying implementation — that both need to change or extend over time without forcing changes on each other.
Key Points: • Useful when you expect to add new implementations frequently, like new platforms, drivers, or backends. • Useful when abstraction and implementation would otherwise require a combinatorial explosion of subclasses if handled purely through inheritance. • Good fit for cross-platform code, where the same abstraction must run against different platform-specific APIs. • Useful when you want to swap implementations at runtime rather than at compile time. • Less necessary for simple systems with only one implementation and no expected variation.
Example: A cross-platform GUI toolkit can separate a Window abstraction from platform-specific WindowImpl implementations for Windows, macOS, and Linux, so adding support for a new OS only means adding a new implementation class, not touching the Window abstraction hierarchy.
Interview Tip: A concise interview answer is:
"I'd reach for Bridge whenever there are two independent axes of variation — like an abstraction and a platform-specific implementation — that both need to evolve separately, such as a cross-platform GUI toolkit where I want to add new operating systems without touching the shared GUI abstraction code."