NetTuts.com has continued their series covering common design patterns and their implementation in some example PHP scripts today. In their latest post they focus on the Facade pattern, a member of the "structural" family of patterns.

When it comes to design patterns, you may have questions: Why should we use design patterns in programming? Our code can work just fine without it. [...] Code that employs design patterns is easy to understand, easy to maintain, and easy to extend.[...] In this tutorial, we are going to cover the facade design pattern. It falls under the category of structural patterns because it deals with how your code should be structured to make it easily intelligible and keep it well maintained in the long term.

They start with a UML layout of a typical Facade and include a typical problem/solution where it could be used. They get into a code example that creates a simple checkout process. In this process, they use the Facade pattern to create a more maintainable, extensible ordering workflow.

Paul M. Jones has started an interesting discussion rethinking the MVC pattern as applied to the web, which he has dubbed Action-Domain-Responder (ADR). If you haven't given it a read yet, click the link and do that; this page will still be sitting here waiting when you return. I agree with a ton of it - heck, I've contributed to it a fair bit via conversations with Paul. But there's been one thing nagging at me for a bit now, and I was finally able to put it into words recently. Controllers - Actions in ADR - can be explained as facades.

Matthew starts off by defining the Facade design pattern with a quote from the infamous "Gang of Four" book: simply put, a simplified interface to a complex system. He provides a basic example of a facade that wraps some common steps for inserting and logging data with this kind of simplified interface. He applies this to the ADR pattern's controllers, pointing out that it handles a few complex steps "behind the scenes" common to marshaling and managing the request.

For me, thinking of Controllers and Actions as Facades has an additional benefit: it describes rather complex architectural patterns in terms of basic design patterns. I find the more I can reduce the complexity of a definition, the more likely I will understand and use it correctly.

On PHPMaster.com today a new tutorial has been posted about using the Facade design pattern to help reduce the complexity of your application. It can help interface between other pieces of code an make using them simpler (a "facade" on top of them).

Design patterns are built to standardize solutions for common problems faced in software development. [...] Facade is a design pattern used in almost every web application, but often without knowing. The term "design pattern" creates a mental image of something complex and difficult to understand. Even though this can be true sometimes, the Facade pattern is simple to implementation. Let's see what Facade is and what it does to help us write good code.

A simple example is given to help make the concept of a facade clearer - the process behind borrowing a book. As borrowing and returning a book could involve multiple library types, they use a facade to provide a common interface to all of them. With the concrete example in place, they then move on to the official definition of the pattern and two more "real world" examples: authentication against multiple social networks and working with WordPress meta functions.

On the Zend Developer Zone there's a new article from Keith Casey where he talks about some of his favorite design patterns he's come across in his time as a developer - adapter, facade and decorator.

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.

He describes each of the patterns (no code in this one, just descriptions) and for each mentions some of the tools that the Zend Framework has to offer that match up. For example, the Adapter pattern is used in quite a few places in the framework including in the Zend_Db component for the connection types to different databases.

DevShed has posted the last installment of their series looking at the use of the Facade design pattern. This time, they're looking specifically at its use in handling file data for the items on the local file system.

I'm going to continue demonstrating the application of the facade pattern, this time by developing yet another illustrative application. It will take care of processing the contents of a selected data file in different ways.

They start from scratch with the development of the sample script - creating a simple class that implements the pattern, then modifying it to work as a string processor and finally pulling them together to read the data for a file and echo out the processed results.

DevShed continues with their look at design patterns in PHP with the first part of a new series today discussing the Facade pattern as created in PHP 5.

In this case, you have a class that hides all the complexity required for serializing the mentioned objects, but there's also a group of classes that know nothing about the class that called them. As you can see, these classes are only responsible for performing the serialization/unserialization sequence on several objects and nothing else. Period.

The Facade pattern is best seen as an interface between the real meat of the application and the part that displays the results. It provides a buffer between the two to make it easier for the output class to call. They create a basic implementation of this and show how to use compression and provide all the code you'll need to get it working.

Patterns in PHP are becoming more and more popular, and sites like this one are doing well to provide summaries of each with code examples to help clarify.

Following my petty wingeing about the design patterns in php on the web I have to bite the bullet and do something about it. So here it comes a collection of design pattern examples, some from the GOF book, some collected from around the net, some (maybe) I have discovered.

The intent of these pages is to show the shapes of the patterns not a fully fledged implementation. In real life probably a combination of patterns will be employed. Everyone has their own favourites following their political, religious and style differences.

He admits that the pages are a work in progress and aren't complete, but they're a start to share his studies with the world. His list of patterns so far includes: