OOP incompatible declaration

jrdbrndt

So I'm working on a server/client system and trying to learn some OOP.

I have set up the following interfaces:

interface Host {}

interface Server extends Host {}

interface Client extends Host {}


interface Message {

public function __construct( Host $x, ... );

}

interface Request extends Message {}

interface Response extends Message {}

This works just fine. No error. I wanted to extends the interfaces in the way that I have, because the client and server will share A LOT of methods, and the request and response will share A LOT of methods. Design-wise, this seems to make sense to me.

But, the Request should only be allowed to instantiate with a Client, and a Response should only be allowed to instantiate with a Server. Something like this:

interface Message {

public function __construct( Host $x, ... );

}

interface Request extends Message {

public function __construct( Client $x, ... );

}

interface Response extends Message {

public function __construct( Server $x, ... );

}

But this doesn't work, because the Message/Request/Response constructors have different signatures. It seems to me that, logically, they are the same, since anything you pass to "new Request()" or "new Response()" would definitely successfully pass to "new Message()", since Client and Server are children of Host, and therefore inherit its public and protected properties and methods.

Nevertheless, it doesn't work, as I'd hoped it would. I have been thinking about this problem for a long time now, and tried various solutions. But, all to no avail. I just keep going in circles.

Can someone explain to me what I'm missing, why this logically SHOULDN'T work, or, if I can make it work somehow? I would appreciate any and all input!! 🙂 Thanks!

laserlight

jrdbrndt wrote:
I wanted to extends the interfaces in the way that I have, because the client and server will share A LOT of methods, and the request and response will share A LOT of methods. Design-wise, this seems to make sense to me.

That actually hints that you might need more interfaces if you really want to do things this way because of the interface segregration principle. Presently, it sounds like these interfaces should actually be base classes instead, since they group together interfaces (as in groups of cohesively related methods) rather than present a particular interface.

jrdbrndt wrote:
But this doesn't work, because the Message/Request/Response constructors have different signatures. It seems to me that, logically, they are the same, since anything you pass to "new Request()" or "new Response()" would definitely successfully pass to "new Message()", since Client and Server are children of Host, and therefore inherit its public and protected properties and methods.

Yes, because with different signatures you get overloading rather than overriding. They may seem the same, but they are not since the base interface specifies a contract that all Host objects can be passed to the constructor, but you have ignored this contract by saying that in the derived interface only some Host objects (e.g., only Client objects) can be passed to the constructor.

Perhaps the solution is quite simple: don't make the constructor part of the interface. Rather, the constructors will be part of the concrete classes that are used to actually instantiate Request and Response objects... and after all concrete instantiation is why constructors exist.

jrdbrndt

laserlight;11065423 wrote:
They may seem the same, but they are not since the base interface specifies a contract that all Host objects can be passed to the constructor, but you have ignored this contract by saying that in the derived interface only some Host objects (e.g., only Client objects) can be passed to the constructor.

That makes sense!! Thanks for helping me understand. I have still got much to learn! I also hope that, now that they've introduced strict typing, perhaps they will introduce "real" overloading!

I appreciate your advice! 🙂