If you've read the About This Site page, you'll know that instead of pursuing my passion for computers, I got sidetracked into the arts in college. So when it came time for me to learn and explain the Factory Pattern, I thought it might be fun to express it as an allegory...

His example involves cars, axles and wood to illustrate how the Factory pattern lets you generate objects of different types automatically without having to worry about how they're created. He includes a code example in the form of an interface and a class that implements it (the "Axle" class).

Unlike mappers, though, which are part of the infrastructure, a repository characterizes itself as speaking the model's language, as it's intimately bound to it. And because of its implicit dependency on the mappers, it preserves the persistence ignorance as well, therefore providing a higher level of data abstraction, much closer to the domain objects.

Included in the tutorial is the full code you'll need to create a simple UserInterface class and a User model that extends it. He also makes a UserCollection class to handle working with multiple User objects and a UserMapper to handle the actual data source fetching. Finally, he implements the Repository on top of this base structure showing how it lays on top of everything via the UserMapperInterface instance. At the end some example code showing it in use is also included - making the PDO connection, creating the UserRepository and fetching by a few different data types (email, name and role).

If your knowledge of constructors ends with "the place where I put my object initialization code," read on. While this is mostly what a constructor is, the way a developer crafts their class constructor greatly impacts the initial API of a particular class/object; which ultimately affects usability and extensibility. After all, the constructor is the first impression a particular class can make.

He starts at ground level, reintroducing what a constructor is and what it should (and shouldn't) be used for. He talks about constructor overloading, constructor injection, dynamic class extension and using the Prototype pattern to create "an unlimited number of objects of a particular type, with dependencies in tact, each with slight variations." He gives an example with a "DbAdapter" class, showing dynamic class instantiation and how to, using the Prototype method, inject a DbAdapter object and have your class use that instead.

In this article I'll show you how to implement the Observer Pattern. You'll learn how various classes in the pattern relate to one another as subject and observers, how the subject notifies observers of a change in its state, and how to identify scenarios where it would be suitable to use the Observer Pattern in your own code.

The introduce the pattern by using an abstract "Observer" and "Subject" (that defines "attach", "detach", "getState", "setState", "notify" and "getObservers" methods) observer classes to coordinate the attached classes. They extend these classes with "Auth" and "Auth_ForumHook" show how to attach the "Auth_ForumHook" classes to the main "Auth" observer manager and change the state of the observer to notify it of an update.

You can find a more detailed explanation of the Observer pattern on Wikipedia.

The current list includes:

• Test Strategy: Scripted Test
• Design for Testability: Dependency Injection
• Fixture Setup: Delegated Setup
• Fixture Teardown: Automated Teardown
• Test Double: Mock Object

There's lots more where these came from, all divided into sections like "Fixture Setup", "Test Double" and "Database Isolation" patterns. You can find the full list so far here.

So far in my series of articles on design patterns in PHP we've looked at a creational pattern, a structural pattern and a behavioral pattern. Today I'll be taking a closer look at another behavioral pattern - the observer. The observer pattern (also known as the Subscribe/Publish Pattern) is used to notify one object, the observer, about a change of state from another object, the subject.

He gives the layout of the pattern in a simple UML diagram before moving into the description and code. His sample builds a Users object that has a set of observers on it. His custom observer is a logger that, when a change is made on the Users, it writes out a value of the current object.

From Wil's post:

I need a word for several engineers working on the same project that isn't 'team'. Why? Because most engineers working on the same project aren't working together as a team. This is why I believe in process patterns. Note: I didn't say that I believe in processes, because I don't. [...] You name a methodology, and I don't believe in it. But I do believe that there are some process patterns that can dramatically improve team productivity.

These patterns are things that are common to several of the processes common to software development - like backlogs, test driven development, etc - but don't have to be considered as something that only comes with XP or Scrum and shouldn't be used outside them. There's even a whole other site dedicated to defining these patterns and where the ideas came from. Oh, and don't forget to add Wil's new word to your vocabulary - "hackle", two or more engineers working together on one project (not necessarily as a team).

The Strategy Pattern is used to decouple an algorithm from the context in which it is used. I'm going to equate this example to a real world scenario starring a man, I'll call him Bob.

In his example Bob heads to work and takes whatever way he wants to get there. His boss only cares that he makes it there, not the path he takes. Bob can take many different ways ("strategies") to get there, but how is up to him. Tom illustrates this with a bit of sample code with a "bob.php" that can use any number of other classes/methods to get to work (like commute, the train or a car).

Hierarchical-MVC has been shown to make large web applications easier to scale out, but there is a price to pay- namely overall performance. This article will investigate ways of improving performance within HMVC web applications using asynchronous processing and some good old caching techniques. Predominantly this article will use examples written for the Kohana Framework; however all the concepts portrayed here could apply to any framework or web application.

He starts by pointing out what's wrong with the typical HMVC application - namely that the clean separation of code structure (the hierarchical part) costs the application in overall speed and memory usage. He suggests a simple technology for helping ease the load - caching as much information as possible, mostly in the HTTP client code since HMVC applications rely heavily on it. Code samples includd show how to implement this in a simple Kohana application.

The list so far includes the patterns for:

• Recoded tests
• Scripted tests
• Data-driven tests
• Test automation frameworks

Keep an eye on this great series. There's more to come that can be quite helpful when you're trying to generate those tests and procedures around them.