In swotting up for my Zend Certified Engineer exam, I decided that I should really knuckle down and learn a bunch of design patterns if I'm ever going to consider myself a true OO coding professional.

Despite the fact that I've been using many of these patterns for years just from code evolution and common sense, until now I've never known which pattern is which and how to discuss them with peers. Indeed, having a common spoken/written language for talking about coding structures makes discussing implementation details much more simple. Design patterns have emerged as the nomenclature of choice for professional software engineers out there, so I hit the web and learned a dozen of them.

In order to remember them all, I've come up with the following anagram:

DISCOS ARE FADS

Going through them one at a time:

Delegate - allows decision making regarding which class implementing an instance to be instantiated to be bundled off to a separate class.

Iterator- allows traversing of lists of objects

Singleton - allows script-wide accessing of single instance objects

Chain of Command - traverse multiple objects to find the most appropriate one to handle a command.

Observer - allows multiple objects to listen to events from a given object

State - implement a finite state machine without loads of nested conditionals

Abstract Factory - handle multiple factories that deliver equivalent concrete objects (e.g. multiple DB driver libraries)

REgistry - global access to a set of objects, with better namespacing than a global array

Factory - abstract away the initialization steps required to instantiate and set up an object

Adaptor - presents data from one class in a format understandable by another

Decorator - alter the functionality of a class without needing to alter the class itself

Strategy - separate the deep level algorithmic implementation from higher level logic by bundling it into a separate class