Comparison
Adapter patternvsBridge pattern
Adapter pattern
the library's method was called differently and returned the wrong shape, so you wrote a class that speaks both.
A wrapper that converts one interface into another the caller already expects, so two things that were not designed together can work together. The intent is incompatibility, and that is what separates it from the other three wrappers: the adapter's interface is deliberately different from the thing it wraps. It is the pattern that keeps a third-party SDK from spreading through a codebase, which is the same argument the anti-corruption layer makes at the service boundary.
Full entry →Bridge pattern
you had shapes and renderers and were about to write one class per combination, so you gave each shape a renderer field.
Splitting an abstraction from its implementation so the two can vary independently, turning a product of subclasses into a sum. It is the answer to subclass explosion across two axes, and unlike the adapter it is designed in up front rather than retrofitted between things that already exist. Most people meet it without the name — any class that holds a strategy for how it does its work is halfway to a bridge.
Full entry →