I guarantee, you already know these patterns. However, the patterns terminology is useful, if only to communicate the concepts quickly.
Builder
An object used to build another object. The most obvious implementation of this pattern in the framework is StringBuilder. It can be quite useful to have a builder in cases where what you’re constructing is complex and you don’t need to read from the constructed object as you’re going. (If you do, just using the object’s own method is often simpler.) The Builder pattern is used in fluent interfaces to support method chaining. In this case, the builder constructs the object internally, but returns itself.
Arguably, this pattern should be marked “Caution: Hazardous Material”. Although everyone is familiar with it, every so often someone gets it into their head that every object should have a builder. The code rapidly becomes a mass of useless indirection.
Adapter
You want to expose one interface from an object, but it exposes a different interface. You write an adapter object to translate calls from one to the other. Differs from the proxy pattern only in as much as the proxy pattern mandates that the exposed and the internal interface should be the same, but it’s definitely a proxy in the looser sense that we commonly use.
Adapters usually occur at sub-system or system boundaries. Third-party libraries should typically be wrapped
Facade
Now, this pattern is so general it’s going to cover a lot of code you’ve written over time, but the terminology is actually useful, simply because we do actually need a word for it. Say you’ve got an extremely complex trading system. However, all that your code needs is a list of accounts and the cash in each. A Facade is an interface that just exposes the bit you need.
Summary
Facade, Builder and Adapter are amongst the most common patterns in software development. Most developers will have independently come up with these solutions, since they’re pretty obvious. The terminology can, however, be useful to communicate between developers.
Bridge and Template are also obvious, but unlike Facade, Builder and Adapter, aren’t really useful for communication.
- In the case of bridge, typically just saying that you’ve hidden something behind an interface is more clear.
- In the case of Template, it’s better to refer to what you’re doing as a parameterized algorithm, irrespective of the form that parameterization takes.
The Flyweight pattern is part of a general principle that objects can have more than one representation. I wouldn’t personally use the term.
There’s one more “obvious” pattern: factory. However, when you should use it isn’t as obvious, so it’s getting a post of its own.
Colour Coding 