Short summary of design patterns — Part II. Structural patterns.

I want to show you a simple catalog of design patterns for object oriented programming that are described in the great book Design Patterns. Elements of Reusable Object-Oriented Software.

In first part of that series I’ve presented creational patterns.

Part II. Structural Patterns

These patterns are about how classes and objects are composed to build bigger structures.

Adapter
With adapter pattern you can convert the interface of a class to another interface that is expected by the client.
Use when: you want to use existing class but its interface does not match the one you need.

Bridge
Decouple an abstraction from its implementation so that the two can vary independently. I described that pattern in my previous post.
Use when: you want to avoid binding between abstraction and its implementation if for example each of them must be selected in runtime.

Composite
Compose objects into a tree structure to represent their hierarchies and allow client to treat them uniformly.
Use when: you want to represent hierarchies of objects.

Decorator
Allow add additional responsibilities to an object dynamically.
Use when: you want to add extensions to an object in runtime without affecting other objects.

Facade
Provide unified interface to a set of interfaces to make it easier to use them.
Use when: you want to provide a simple interface to a complex subsystem.

Flyweight
Use sharing to support large number of small objects.
Use when: an application uses a lot of small objects and their storing is expensive or their identity is not important.

Proxy
Provide placeholder for another object to control access. 
There are few kinds:
* remote proxy — provides local representation of an object in a different location/address space,
* virtual proxy — creates expensive objects lazily only when they are needed,
* protection proxy — controls access to the original object.