In this new post Ralph Schindler takes a look at the Prototype design pattern and uses it to illustrate some best practices in using constructors in PHP.

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.

Anthony Ferrara has a new post to his blog sharing some inconsistencies with iterators that he discovered as discussed with a fellow developer - why some iterators only accept Iterator arguments and others don't.

We were talking about why some of the SPL Iterators accept only an Iterator as the constructor argument (Such as LimitIterator), and others accept either an Iterator or an IteratorAggregate as the argument (Such as IteratorIterator). Feeling that this would be a useful feature to add (having all of them accept an IteratorAggregate), I opened up the PHP source and started looking at how hard of a change this would be. What I found was... Interesting...

He shares some of the C code he came across in his investigation including a "WTF" moment when he found a case statement for DIT_IteratorIterator in a constructor. Because of some of the logic in this constructor, the inputted iterator is "cast down" to a class. This is shown in a few code examples comparing simple iteration objects and arrays and how it seems to be able to bypass class inheritance to use methods from other classes.

In a new post to his blog Paul Jones talks about spotting something "in the wild" that he's a proponent of - a "universal constructor".

For those of you who don't know, "universal constructor" is the name I give to PHP constructors that always and only take a single parameter. The parameter is an array of key-value pairs, which is then merged with a set of default keys and values. Finally, the array is unmarshalled, usually into object properties.

He talks about the benefits of using a constructor like this in your applications and how he's implemented it as a standard part of the Solar framework. Oh, and the sighting in the wild? It was in this MongoDB session handler.

Be sure to check out the comments for some other great opinions on this "universal constructor" idea, both for and against.

Patrick Allaert has put together a shell command that can take your PHP4 code and replace its current constructors with PHP5-formatted ones.

It assumes your classes are always declared with the class keyword starting at the beginning of the line and that your files have the .php extension.

It uses a regular expression in a perl command to search through the current directory and look for the ".php" files to replace the "function ClassName" sort of thing with a "function __construct".

Fabien Potencier has posted a look at dependency injections - what they are and how they can effect your code (usually for the good).

Dependency Injection is probably one of the most dead simple design pattern I know. And odds are you have probably already used Dependency Injection. But it is also one of the most difficult one to explain well. I think it is partly due to the nonsense examples used in most introductions to Dependency Injection. I have tried to come up with examples that fits the PHP world better. As PHP is a language mainly used for web development, let's take a simple Web example.

His example uses a session variable, setting it to a language preference and wrapping a class around it to handle the getting and setting. The dependency injection comes in when he adds a SessionStorage class into the mix, a tool that could change the place and method where that session information is held. He suggests that the best place to set these kinds of dependencies is usually the constructor but it can be done as a setter or property injection too. It just depends on the need for the script at the time.

In this new post from Lars Strojny, there's a discussion of an "antipattern" - using the constructor for more than it was intended, the "verbose constructor".

Constructors are often used to shortcut dependency injection and parameter passing on instantiation. This is a valid practice and often leads to shorter code. [...] Instead of creating a new instance of "Money" and calling three setter, everything can be done compactly in the constructor. [...] So for the money object this works pretty well. The code is easy to read, but wait, the first argument can be grasped easily, the second too, but the third? It is not too obvious that it is a divisor is passed.

He compares three different ways to get the data into the class - the already-mentioned parameters in the constructor, passing an array into the constructor and using full getters/setters to push the data into the right places (with fluent interfaces even!).

On the PHP::Impact blog Federico Cargnelutti has posted a comparison of using static factory methods to create an instance of a class versus making an object, calling the constructor.

Normally, creating an instance of a class is done by calling new, which calls the constructor. Static factory provides a static method that returns an instance of the class. So, you are using static factory instead of the constructor. Providing a static factory method instead of a public constructor has both advantages and disadvantages.

He includes some of the advantages of the factory method and others for the normal call to create an object. He also mentions some comments made by Dagfinn Reiersol in a blog post about public constructors.

According to the PHP in Action blog, public constructors can be hazardous to your (application's) health and should be replaced.

Everybody who writes object-oriented code knows about constructors. You need them so the program knows how to instantiate objects, right? And you especially need them when a lot of things have to be done while instantiating an object. [...] So why would I be skeptical of public constructors?

The solution, as he sees it, is to make a "constructor" that's actually called statically with parameters that returns an instance of the class it's in as well as performing the action. He argues that this can help make the code much more readable for some types of method calls.

In a new blog post today, Hasin Hayder points out an interesting bug he found in the Reflection functionality that's offered in one of the latest PHP5 series release, version 5.2.1 (also found in 5.2.2). It deals with an issue in the ReflectionParameter object.

[Despite the closing of this bug] there is still the following bug alive in ReflectionParameter object, I tested it against the PHP version 5.2.1 . So what is this bug? The reflection parameter cannot retrieve the default value of a parameter if the next parameter has no default value. PHP simply omits all the variables before that variable and return only values after that variable.

He illustrates with a test class that uses reflection to get the parameters for the constructor. Unfortunately, the object only comes back with the last attribute. This is solved later in the comments, however, when it's discovered that the parameters, some of which are optional, are not in the "correct order" - optional parameters should always follow the required.

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.