The question is about typehinting of the role interfaces.
The code example has two DataMappers which typehint the interface they need in the constructor,
FooDataMapper type hints the Preparable interface. Because it dependens on it and no other method from the dependency.
In the other mapper, BarDataMapper i replaced the type hint with ??? as it requires both the Preparable and the Queryable interface.
How do i handle this (what should replace ???), typehinting a single of them would not suffice, should i make a new interface (maybe one that extends the previous mentioned) and hint this new interface?
The code example is a boiled down example in PHP and the type hint (???) is in the last Class declared.
<?php
// TWO ROLE INTERFACES, SMALL SEGREGATED PART OF A DBAL
Interface Preparable {
public function prepare( .. );
}
Interface Queryable {
public function query( ... );
}
// ADAPTER IMPLEMENTS SEGREGATION
class DbalAdapter implements Preparable, Queryable {
private $dbal;
public function __construct($dbal)
{
private $this->dbal = $dbal;
}
public function prepare( .. )
{
..
return $this->dbal->prepare( .. );
}
public function query( .. )
{
..
return $this->dbal->query( .. );
}
}
// DATAMAPPER CTOR HINTS FOR METHODS IT NEEDS TO USE
class FooDataMapper implements DataMapper {
private $dbal;
public function __construct(Preparable $dbal)
{
$this->dbal = $dbal;
}
public function create(Foo $Foo)
{
..
$this->dbal->prepare( .. )
}
}
// DATAMAPPER CTOR HINTS FOR METHODS IT NEEDS TO USE
// BUT THIS TIME NONE OF THE ROLE INTERFACES MATCH, BUILD A NEW INTERFACE?
class BarDataMapper implements DataMapper {
private $dbal;
public function __construct(??? $dbal)
{
$this->dbal = $dbal;
}
public function SomeMethodThatNeedsBothPrepareNQuery(Bar $Bar)
{
..
$this->dbal->query( .. )
$this->dbal->prepare( .. )
}
}
The initial solution i come to is making a new interface extending the ones needed.
Beware the naming of classes in the code are only for shown, might as well have been Fooable, BarAble…
The consumer of dependencies is the one responsible for defining them (by means of their interfaces). In your example, BarDataMapper rules. I see two possible scenarios:
-
If
BarDataMapperdepends on a single object implementing bothprepare()andquery()methods, then yes, a properPreparableAndQueryableinterface should be defined including the two of them, and passed to the constructor. But then, perhaps you want to find another meaningful, non-composed name not hinting at bad separation of concerns. -
If it makes sense for
BarDataMapperto consume independentPreparableandQueryabledependencies, then its constructor takes them as separate parameters, even if in the end there’s really one single object implementing both interfaces. Who’s really implementing interfaces should not bother the one consuming them.
1
I think you are standing on one edge case, which can either mean that you have pushed software engineering in some place where PHP can’t help you much or that you have some kind of conception problem.
According to the interface segregation principle the DataMapper interface should be strict enough for you to set one interface and one only that all your DataMappers implementations should match. Those implementation shouldn’t expect any more specialized object.
One possible solution for your problem of using two interfaces at the same time, you could use traits with abstract methods (if >= PHP 5.4) instead of interface. But I wouldn’t do that since it’s trying to mimic “interface inheritance” by using traits composing capability.
If what you want is suggestion in your IDE you are not constrained to use type hinting (which is what you are doing). You can use the PHPDoc and your IDE may recognize what you are doing (I keep recommending PhpStorm):
/**
* @param MySuperClass $a
* @return void
*/
public function myFunction($a) {
// Here your IDE will know what kind of object is $a
}
Last point: don’t try to do Java with PHP. At some point if you want to ensure what is the provided object you can use quick introspection to check the right usage of the right classes, subclasses, traits and interface.
2