I'll play nice if you tell me what that means

Lukas Kahwe Smith wrote an article about keeping the parameter order intact when overloading the parent Exception’s constructor. He feels that by rearranging the parameter order the child no longer follows the contract of the parent. This is confusing and an ‘OO no-no’, according to him. In another recent article Keith Casey talks about this issue as well.

Ah, le Judging Other People’s Code, it is dangerous. There can be various things wrong with code, such as it lacking a consistent code style, being badly structured, not compiling and of course not producing the expected result. When in OO land, code can be un-SOLID (I will post an article about SOLID RCC ASS soon).

Before we dive into the practicalities, I want to take a moment to remind you of an article I wrote earlier. Writing bad code does not make you a bad person, it just makes your work less valuable. That’s all.

Is it wrong to change the parameter order when overloading constructors?

Alright. Practicalities. The use case of a constructor method call is very specific, because the constructor is, under any reasonably regular circumstances, a one-time call. And polymorphism doesn’t have anything to do with it. Why not? Because you explicitly name the class you are calling. In theory, I am completely right here (I think). If you want to be really harcore OO DiC then you will have some Factory object dealing with instantiating your code.

Now, the problem is that this works in PHP:

$className = ‘ParentClass’;
if ($conditionX)
{
      $className = ‘ChildClass’;
}
$object = new $className($param1, $param2, ...);

This could almost pass for a factory method. We decide at runtime, based on some condition, which class we are going to instantiate: the parent or the child. However, this extreme use case, only applying to PHP and similar dynamically typed languages, is not for exceptions. Why would you want to dynamically decide the type of exception that you will be returning? I don’t know.

So I can think of no theoretical or practical reason why it is wrong to change the parameter order. That doesn’t mean there is no reason, of course.

What is ‘playing nice’?

‘Why do I care? I don't want to have to guess what the order is for standard stuff.’ I can certainly relate to this, but this is a problem that is not so much inherent to the library you’re calling as it is to the editor you are using. I have a lot of classes in my mind that I use daily and thus know how to call, but there are a lot more that I couldn’t possibly remember. I will have to guess (read: look up) how that code works, but that’s not an argument to keep from writing new code.

Ok, so don’t exceptions form an... exception? I wouldn’t know why they would. I can imagine that a host of exceptions are only interested in messages and code, but I guess a great many exceptions aren’t even interested in a message. Webstruct certainly has a lot of exceptions that only get context identifier arguments and the exceptions write their own messages. These exceptions in Webstruct have always worked well for me, because they are well-defined and well-documented, which means it’s clear when to throw or catch one and how to do that. The author suggests I should use a factory instead. He doesn’t mean factory though, he means adding a static method that is actually a sort of constructor. To me, that is an OO nono, because static functions are the worst when it comes to dependency injection.

Platform or player?

Writing different constructors with different parameters is commonplace on platforms such as .NET or Java. These environments allow children to inherit their parent’s constructor and write new constructors for their own use cases. PHP can’t do this, which is a seriously limiting handicap. Why not get angry at the team behind PHP, instead of getting angry at the humongous group of PHP developers who work with what they got, despite the language’s quirks?

Closing thoughts

On a final note, the author is saying that he sees ‘top notch and usually very careful developers make this mistake’. With all due respect, this is not a very nice thing to say, especially not when you’re not entirely right. Having a preference is one thing, but claiming a principle is entirely different grounds. And to claim, on top of that, that top notch developers make a mistake when they don’t follow your principle… that’s arrogant.