Wrapping and composing

the object holds another object and forwards most calls to it, and which pattern that is depends entirely on why.

Wrapper

the library's method was called differently and returned the wrong shape, so you wrote a class that speaks both.

Adapter pattern

one version holds the adaptee in a field and the other inherits from it, and only one of them can adapt a subclass.

Object adapter vs class adapter

you replaced eleven calls across four classes with one method, and callers stopped needing to know the order.

Facade pattern

you wrapped the same interface in retries, then logging, then caching, and the caller still sees one thing.

Decorator pattern

the object looks and behaves exactly like the real one, and its whole job is deciding whether the call gets through.

Proxy pattern

you had an object with an id and nothing else, and touching any other property fired a query.

Virtual proxy

the call looked like an ordinary method on an ordinary object and it went over the network and timed out.

Remote proxy

logging appeared around every method in the service and there is no line of your code that calls it.

Interceptor

you had shapes and renderers and were about to write one class per combination, so you gave each shape a renderer field.

Bridge pattern

a folder and a file answer the same size method, so the code that totals them never checks which it has.

Composite pattern

a million objects turned into a thousand shared ones plus a million positions, because most of the data was identical.

Flyweight

the character knows its glyph and not its position, because the position was moved out to the caller.

Intrinsic state

everything is inside one function that returns an object with three methods, and the rest is unreachable from outside.

Module pattern