Structural patterns

Structural patterns solve how to assemble classes and objects into larger structures, keeping those structures flexible and efficient even as the individual pieces change.

Signs the problem falls into this category:

• You need two incompatible interfaces to work together without modifying either one.
• An abstraction and its implementation are mixed into the same class hierarchy, and changing one forces you to touch the other.
• You need to treat an individual object and a composition of those objects uniformly (a file and a folder containing files, for instance).
• You need to add responsibilities to one specific object without an explosion of subclasses for every possible combination.
• A subsystem has so many pieces and internal dependencies that the code using it becomes hard to follow.
• You have an enormous number of very similar objects, and that’s consuming too much memory.
• You need to control or intercept access to an object without the code using it noticing.

The seven patterns in this category:

• Adapter — lets two incompatible interfaces work together by translating calls from one to the other.
• Bridge — separates an abstraction from its implementation so both can evolve separately.
• Composite — composes objects into tree structures and treats them uniformly, whether they’re leaves or compositions.
• Decorator — adds responsibilities to an object at runtime by wrapping it in another compatible object.
• Facade — exposes a simple interface over a complex subsystem.
• Flyweight — shares common state across many similar objects to save memory.
• Proxy — places a stand-in in front of an object to control access to it.