Comparison
Bridge patternvsSubclass explosion
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 →Subclass explosion
adding a third colour to a hierarchy that already had four shapes meant writing twelve classes instead of one.
What happens when two independent axes of variation are both expressed as inheritance: the number of classes becomes the product rather than the sum. It is the specific pain the bridge pattern exists to remove, and the strategy and decorator patterns are variations on the same escape — turn one of the axes into a field instead of a subclass. Recognising it early is the difference between four classes and forty.
Full entry →