The Dependency Inversion Principle#125
Conversation
|
@oschwald what do you think about this feature? |
|
@oschwald may you merge & release this please ? It's impossible to test our implementation using |
|
Is there a reason why you cannot just mock the reader via |
|
Hi @oschwald, my code depends on I you are septical about BC, maybe can you release a new major 3.0 with this interface. In all cases, the BC is easy to address. |
|
My concern about breaking changes is that every new method added to the interface is a breaking change. This would cause us to have many more major releases, which often make people hesitant to upgrade. I suppose one "solution" would be to say the interface is not covered by our semver versioning, but that would likely lead to confusion as well. |
|
When you add a new method, you can always create a new interface that extends Ex : Now in 2.x interface ReaderInterface
{
public function city($ipAddress);
public function country($ipAddress);
public function anonymousIp($ipAddress);
public function asn($ipAddress);
public function connectionType($ipAddress);
public function domain($ipAddress);
public function enterprise($ipAddress);
public function isp($ipAddress);
public function metadata();
public function close();
}When you add a new method in 2.y you can decorates interface SuperInfoInterface extends ReaderInterface
{
public function mySuperInfo($ipAddress);
}
class SuperInfoReader implements SuperInfoInterface
{
private $decorated;
public function __construct(ReaderInterface $decorated)
{
$this->decorated = $decorated;
}
public function mySuperInfo($ipAddress)
{
...
}
public function city($ipAddress)
{
return $this->decorated->city($ipAddress);
}
...
}In 3.0, you will merge |
I add a Reader service interface to add the ability to invert dependencies.