Within the Design Patterns world, there are four main categories: Architectural, Structural, Creational, and Behavioral. Architectural patterns describe the system as a whole, Structural patterns describe the relationships between objects, Creational handle creating objects, and finally Behavioral describe the communication patterns between objects. Each of the categories is worth discussion on its own, but in this case we'll stick to the Structural patterns of Adapter, Facade, and Decorator.
The Adapter Pattern is the most common of the three. In simple terms, it's used to "wrap" another library or system to allow you to interact with each of them in the same way. It's powerful because your core code can usually be simpler and even ignorant of the differences behind the scenes. Since one of the goals of good Object-oriented Design is encapsulation and data hiding, the Adapter serves an important role.
If you're using the Zend Framework, you're already familiar with Adapters. Within Zend_Db, we have the Zend_Db_Adapter_Abstract which defines the structure for the rest of the database connectors. Therefore, we get classes like Zend_Db_Adapter_Pdo_Mysql and Zend_Db_Adapter_Pdo_Mssql which allow us to connect, handle transactions, and a variety of other actions without caring about the implementation details.
At first glance, Facades look quite a bit like Adapters in that they both "wrap" another libraries or systems to hide the implementation details but Facades take it a step further. They create a sort of translation layer that simplifies interacting with the other system. This simplification can be useful if objects are difficult to instantiate or use but it's even more useful if the other guy is a knucklehead with a poor API design.
For example, if you wanted to integrate with Flickr, you have to handle the user's API key, create the hash properly, form the requests, make the request, retrieve the results, and process it. Even if you know all the steps and process, it can still kill a day or two of your time. And then you still get to worry about all the functions you didn't implement. Luckily, the Zend Framework implements the Zend_Service_Flickr. Instead of worrying about all those pieces, you feed it an API key, set a few parameters, make the request you want, and process the results with the build in Zend_Service_Flickr_Result. What used to be a day of effort is now a few hours at worst.
The Decorator Pattern is the oddball of the bunch. Instead of wrapping an object to change its interface, it wraps an object to effectively add behavior within the object itself. Yes, you've read that right. In more Computer Science terms, it lets you bypass the limitation of single inheritance to add common behaviors across types of objects. Regardless, this isn't a new concept – Ruby has "mixins" and PHP 5.4 will have "traits" – but the concept is fundamentally the same.
Within the Zend Framework, Decorators are used heavily with Zend_Form, especially for rendering. By adding custom renders to process specific elements or the entire form itself, we can tune the behavior and visual layout without modifying the underlying form. This might seem complex and painful at first glance.. and it can be but once you consider "separation of concerns", it begins to make sense. It allows us to define our forms in one place, add Decorators to add element id's and additional html tags, and then we hand the result to the View layer.
And now our designers can't break it..
Overall, this is just a sample of the Design Patterns out there.. in fact, they're only a small set of the Structural Patterns, but these few seem to be the most common by far. More importantly, they each provide simple ways to add or transform functionality and generally make our jobs easier. More important to me, there are clear examples of each pattern we can review, explore, extend and mimic so we don't have to figure it out on our own.