As a part of his "Advancing PHP Developer" series, Eran Galperin has posted part five, a look at design patterns and what they can do for you and your application.

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.

On the SitePoint PHP Blog today Troels Knak-Nielsen asks th3e question "what's so bad about the singleton?" For all of its advantages, is there a darker side of the design pattern when it pertains to global variables.

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.

Michael Girouard has pointed out that things in the PHP world are one step closer to being able to create an abstract Singleton object via a simple script he's shared.

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).

On the Make Me Pulse blog today, Antoine Ughetto takes a look at one of the more handy things in programming - design patterns. He specifically looks at the Singleton pattern this time - complete with explanations and code examples.

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.

Knut Urdalen, on seeing some of the recent discussion on why the ActiveRecord pattern sucks and talks about why, when presented with a the need for a database layer, he usually goes back to his own familiar Singleton-based style.

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".

Fernando Bassani has posted an alternative to using globals in your scripts - creating "global objects" with the help of the Registry design pattern.

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.

In a new tutorial on the Developer.com website today, they explore the difference between (and the benefits and disadvantages of) the singleton pattern versus threading in a PHP application.

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.

While developing a new application in a framework, Nick Halstead came across an "oops" point where he realized that the part of the application he was working on could have been coded better. In this instance, he found a spot where he needed to pass data backwards and forwards through the app without loosing "the flow". His solution? Singletons!

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.

Tobias Schlitt has provided a helpful hint for developers working with lots of objects, methods, and singleton patterned functionality to keep out of the same trouble he faced.

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.

Matthew Weir O'Phinney wonders about singletons. He wonders how he can make them more flexible than they even are by making entire custom singletons accessible later, after they've been created.

This morning, I was wondering about how to extend a singleton class such that you could retrieve the new class when retrieving the singleton later. In particular, Zend_Controller_Front is a singleton, but what if I want to extend it later? A number of plugins in the Zend Framework, particularly view helpers and routing functionality, make use of the singleton; would I need to alter all of these later so I could make use of the new subclass?

He gives two code examples to illustrate his point - one that uses the current Zend_Controller_Front implementation to extend an instance and the other with a slightly modified version to do the same. The change is in the declaration of the $_instance value. By making it protected, the differently extended instance will be created. With the normal setting (private) you'll only ever get back the same default Zend_Controller_Front instance.

Check out the comments for some other suggestions as well.