As far as I understood it is already not possible languages like Java, C# etc. Because the method name of defining constructor in these languages must be same with the class name. That because I'll talk about PHP which creating the constructor is more abstracted from the class name.

    public function __construct(Type1 $arg1, Type2 $arg2)

Basically it is possible in PHP to enforce construction in interface.

interface MyInterface {
    public function __construct(Type1 $arg1, Type2 $arg2);
    public function method1(Type3 $arg1) : Type3;

class MyClass implements MyInterface {
    public function __construct(Type1 $arg1, Type2 $arg2)
        // Implementation.
    public function method1(Type3 $arg1) : Type3
        // implementation

$object = new MyClass(new Type1(), new Type2());

So basically it works. If I try to define constructor implementation different than the interface basically it gives me the type error. Which is very nice you can enforce object construction behaviour with a contract. But I haven't seen this practise in other OOP Languages what I mean Java is more OOP than PHP and it dominates the OOP world.

So here some of my questions :

  1. Is that practise has some pitfalls that I don't see ?
  2. There is nothing stated this situation in manual or I haven't seen yet. Is this may be a harmless bug in PHP ?

Basically when we go through inheritance if we enforce the construction of a class then it also enforces the sub classes constructors or have same signature. Otherwise there is only function overload is possible with constructors in PHP. It just blocks this behaviour and can harm extensibility over inheritance.

But also final keyword aims to finalize inheritance so enforcing them for final classes and/or the classes that we don't want to let overload it's constructors? Do you think is this a good idea ?

I would like to hear some ideas and clarification I may abusing the behaviour I like to understand clearly.

  • The more constraints you put on your data types, the better, as you decrease the run-time possibilities and make it easier to prove correctness. The constraints can always be relaxed as needed. Interfaces in the other languages you describe are less useful than base classes with constraints for exactly this reason. Interfaces serve only to work around restrictions in multiple inheritance in those languages. Commented Sep 29, 2017 at 16:57

2 Answers 2


The goal of interface is to abstract the implementation.

This is why usually you don't see constructors, the constructors of a class are on the side the implementation.

Forcing a constructor is basically forcing an implementation detail, which may not what you want. Imagine a persistant interface, that both an XMLStorage and DatabaseStorage implements, it's very unlikely that they need something in commons that would make their way to their constructor (one would take the folder where you store the XML file, the others would take the connections parameters).

Furthermore, this has literaly no use with an interface only because even if you can force the constructor in MyInterface you still have to call new MyClass.


Here is another perspective. With interfaces you pose abstractions found by behavioral domain decomposition. Interface methods represent the responsibilities of your domain concepts, so your concrete implementations can be used polimorphically. But polymorphism implies that an object is already created, so putting a constructor in an interface is semantically wrong.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.