PHP in Action

Agreed. This makes it much easier to add in debugging code, or logging, or whatever. One change, multiple additions!

I understand your argument for readability and maintenance, but I fail to see how a public constructor could be "considered harmful." "Harmful" is such a strong term, and I was anticipating from your post title that you would be talking about some unknown security vulnerability. :-)

Using static method is just as bad. Using Redirect::withUrl() fixes the implementation you have to include. Factories, Locators, or Dependency Injectors are far better.

The GoF text calls this the “Factory Method” pattern. I think it’s a useful technique for when a previously-initialized instance might be returned, such as a pool of objects where the new operator is obviously wrong. It can also make the code’s intent clearer when there are several different ways to initialize a new instance. I have also seen it used in the context of an “Abstract Factory,” where the object returned may be of a concrete subclass of the (possibly abstract) class that defines the method.

I'm not sure that test-infected programmers will consider this. Private methods are evil, and thy never write what they cannot test.

I'm not sure that test-infected programmers will consider this. Private methods are evil, and thy never write what they cannot test.

This method could prevent having to modify dependent classes in some cases where the actual constructor needs to be modified. You could have also said: public static function withUrl($url) { return self($url); } In my code I tend to have a Page class with a static Redirect function. Seems pretty readable to me.

Mixed grill of comments to the comments: Sure, "harmful" is a bit of a strong word, but it appears to have drawn attention. I've never had so many comments before. And insightful ones, too. I am a test infected programmer, and I'm OK with testing the constructor indirectly through the creation method. And yes, Factories, dependency injection are excellent, but sometimes it needs to be simpler.

using static factories helps me to manage caching/pooling features and more. Basically something like that:
public static function getInstance($id){
global $cache;

if($cache->contains($id)){
$a=$cache->get($id);
}else{
$a=new myClass($id);
$cache->add($a);
}

return $a;
}

This is not something I've thought about before, but it's an interesting idea. It also has the benefit on attaching more meaning to the argument that needs to be passed.

Two quick nitpicks:
* header("Location: $url"); should be header("Location: {$this->url}");
* You can do away with __CLASS__ by just using self (at least on PHP5). i.e. return new self($url)

(I'm sure the formatting will be a mess, but I can't find a link to a list of valid markup)

@dagfinn: While I understand that using the word "harmful" is a good attention-getter, what does it teach PHP programmers who are new to OOP? I don't think an argument can be made here for using static factory methods over constructors as being a "best practice." It's really an application architecture decision. The truth is: well-documented code can solve this problem, and using something like PHPDocumentor with PHP docblocks can provide clarity for your entire team with regard to the parameter list for a public constructor. Using the static factory method is definitely a great tip and can improve readability, but we shouldn't mislead programmers into thinking public constructors are harmful. :-)

@Ben: I appreciate your point, but I'm not trying to teach basics. I'm thinking out loud about something that the gurus appear not to have considered so far. (I haven't seen it discussed before, anyway.) Maybe I should have made that clearer. It still seems to me that an intention-revealing creation method (it's not strictly a factory method) is superior to a plain constructor. I share Jared's skeptical attitude to static methods in general, but plain constructors have the same problem, since the client code has no instance avilable that can be replaced with one belonging to another class (as in Abstract Factory). As for documentation, my view is that method naming is more important and robust, because it's much harder for it to get out of sync with what's happening in the code.

@Matthew: I fixed your nitpicks. I thought I could implement it untested, but I couldn't. Why am I not surprised? ;-)

I can't resist it'd be a bit better like this Redirect::withUrl("http://www.example.com/index.php")->execute();

Delphi (ObjectPascal) doesn't use the 'new' syntax at all, though it does have 'constructors'. In a Delphi class, the default constructor is always named Create, but you can have other constructors with other names - by convention, these usually begin with the word Create, so you would have something like:

(in the class definition:)
constructor CreateWithURL( url: String );

(in the calling code:)
redirection := Redirection.CreateWithURL( "http://....");

The fact that CreateWithURL is defined as a constructor rather than a class (static) method changes the semantics of when/how it can be called, and what happens when it is called.

I like this style of constructors because it retains the constructor semantics while giving you the self-documenting benefits of creation methods.

Of course, with named constructors, the normal 'new' syntax would have to be changed to support identifying which constructor you want to call using something other than parameter types, and you'd need some syntax to identify that a method is a named constructor rather than some other type of method.

My first comment would be that a static method named "withUrl" is maybe not significative (as static methods are not used only for creation). I would suggest to always use something that explains that the method will create an instance like Mark Shapiro explained with his Delphi example (e.g. create*).

Of course, someone that want to put the emphasis on the "new" keyword might want to do a pattern that support code like new Redirect("with_url", "http://www.example.com/index.php"); -- but that is only another way to do a same thing and might have the disadvantage of being less obvious, less separated, etc. (but now we enter into more subjectivity!)

All in all, naming a constructor when it has parameters might be more significative (and having a default [public] constructor with no data might be OK -- as a lot of case are like this, so making it private might not be OK, unless you want to explicitly do static "create" method for each of your class!).

My second comment to niKo: ... or if OO is not important... redirect_url("http://www.example.com/index.php");