• Strategy and Bridge - The Strategy and Bridge patterns provide solutions to apply polymorphism in more flexible way than you can accomplish with only inheritance.
• Value Object - The Value Object pattern has, just like the Singleton, to do with referencing and instances. In a way, the Value Object is the opposite of the Singleton: it's goal is to ensure NOT to use the same instance, under certain conditions.
• Singleton and Singleton Registry - The Singleton pattern ensures that you are always dealing with the same, single instance, wherever in your application. The Registry pattern usually utilizes the Singleton pattern (hence "Singleton Registry") to make the same 'globalness' apply to objects who's classes weren't necessarily designed to

Keep checking back to their tutorials section for more design pattern tutorials.

A design pattern is a general reusable solution to a recurring design problem in object-oriented systems. Design patterns are essentially blueprints that suggest how to solve a particular set of OO design problems while adhering to OO best good-practices (which I've recounted in my Object Oriented part of this series).

He talks about one of the most popular examples - the Model/View/Controller design pattern that is used in many rapid development frameworks for PHP (including CodeIgniter and the Zend Framework). He also briefly mentions a few others like the composite, singleton and decorator patterns.

Other parts of this series include looks at testing, refactoring and coding standards.

As I have often taken this stance myself, I found it reasonable that I should be able to argue for it, so I'll try to give an explanation. This is also in part a follow-up on my post from last week, in which I present a way to avoid global symbols, without spending much time on why.

He talks about what they are and how they're commonly used - sometimes with some unpleasant side effects because of their use of globals.

The singleton is an incredibly useful pattern in PHP for many reasons. I tend to find myself using them when I know I should be using static classes, but can't because of PHP's lack of proper class name discovery in extended static classes.

[...] And that works like a charm every time. The problem is, in one application there may be several classes that need to be singletons. In which case my first thought was to build an abstract singleton.

Unfortunately, it didn't quite work like he'd thought it would. He did, however, come up with something that did work - creating an interface and making an abstract implementation of it (code example for this included).

The singleton can be use in lot of different cases. In this example we will make a MySQL connection Singleton class. This will help us to always use the same connection.

The code not only shows how to make the class using the Singleton but how to use it in your app - calling it with a SQL statement to make your request.

I normally use a simple solution using the Singleton pattern for managing the database connection, the Value Object pattern for all business objects and the Data Mapper pattern to manage the mapping between business objects and the database schema. It's as simple as that '" handcrafted and no magic going on.

The post also includes his code for an example of a database connection - the creation of the Singleton interface class, making the Value Objects and customizing one for the type of "Product".

For a long time, the "programming good practices" tell us to avoid globals. In fact, this is a point of a large criticism in languages such as PHP. A nice solution to our global's "needs" is the Registry design pattern. With it, we can have a repository with the data that has to be accessible, removing them from the global scope.

Included in the post is all the code you'll need to get it to work. It uses a Singleton to grab the latest object and allows you to store values and define namespaces to keep data separate.

Although you probably could address some [of these] issues with the judicious use of synchronized blocks, do not overlook the utility of the ThreadLocal class. In this article, I will demonstrate the risk of not accounting for Threads when using a singleton pattern and show how simple it is to address.

They start with the creation of a ThreadLocal class, one that allows the developer to communicate with the threads, and its usage. In contrast, they also create the Singleton class, showing the creation method of multiple objects of the same type.

They do, however, point out an issue that the threaded method has - unreliable results. Help is on the horizon, though, in the form of a HelperFactory class to manage the connections a bit more efficiently.

One of these situations occurs when you suddenly that find you don't have access to data you want, or you can't pass back (or forward) data as part of the common flow of your application. [...] The solution was to create a singleton class which uses references to bind a name to a already defined variable.

In his example, he illustrates (and explains) how to use a class he developed (varmap) to handle the assignment/removal/etc of the data to the common Singleton object.

During my current exam phase I'm working on some tiny private project to relax after learning. In there I'm using a main controller class, which implements a singleton pattern and initializes several sub-controllers while being created. The singletons purpose is, that the other controllers can access to main controller and its functionality whenever they need, without storing a reference each.

The problem with the code (he gives snippets) was a recursive loop that was suddenly appearing. He finally tracked it down to a constructor in another class that was accessing the main controller's constructor. The issue was that the constructor was never finishing up, so a valid instance wasn't returned, so the whole thing started all over again.