DBAD: Constructors in PHP interfaces

Interfaces are a wonderful thing and they allow developers to build brilliantly flexible things with defined boundaries and contracts. However, like any good thing they can be misused. #

Earlier this week I was messing around with a Zend Framework 1 application trying to make it do something a bit differently by extending some of its core classes. It was all going so well until I setup my new sub-class on the front controller and then got an error telling me that my class did not match the interface one if its parent classes was implementing. After having a little dig, I discovered that the interface in question had put a constructor in the interface, meaning that any implementing class had to have the same constructor declaration.

interface Foo
{
    public function __construct(Bar $bar);

    public function doSomethingWithBar();
}

I wanted to inject a couple of my own dependencies for this new sub-class in order to provide the functionality I was trying to add. At this point I either had to abandon my attempt or fork and modify a third-party framework. Neither are the kind of options any developer likes to be faced with.

Now there may be good reason for doing that and you might argue that I shouldn’t have been trying to extend it anyway, however there’s a wider point here. If you are building a library or framework for public consumption and you find yourself putting a constructor on an interface, stop and consider whether you really need to do that. Because it will stop anyone coming along and extending it for their own purpose and that is very frustrating.