Как перейти к конкретной реализации при использовании принципа Dependency inversion?

Question

[Alex_Gerasimov]

Принцип заключается в том чтобы вместо конкретных реализаций использовать высокоуровневые абстракции.

Пример:

interface ProductCreatorInterface
{
	public function create();
}

class ProductCreator implements ProductCreatorInterface
{
	public function create()
	{
		return new Product();
	}
}

class ProductController
{
	private $productCreator;

	public function __construct(ProductCreatorInterface $productCreator)
	{
		$this->productCreator = $productCreator;
	}

	public function createAction()
	{
		$this->productCreator->create();
	}
}

Если в контроллере на строчке "$this->productCreator->create();" перейти через IDE к реализации метода create(), то произойдет переход к интерфейсу ProductCreatorInterface, так как он указан в type hint в конструкторе контроллера. То же самое касается и подтягивания документации — она будет подтягиваться из интерфейса, а не из конкретной реализации.

Ну в общем получается не очень удобно — да, я абстрагируюсь от конкретной реализации и могу легко их заменять в случае необходимости, но если нужно перейти и посмотреть какая конкретно используется реализация приходится сначала переходить из кода к интерфейсу, а потом искать где этот интерфейс используется в данный момент.

Задавался ли кто-то таким вопросом и получалось ли его решить?

Comments

[Илья]

Думаю вопрос тут больше в IDE...

[Alex_Gerasimov]

Илья, я пробовал в PhpStorm и в Visual Code Studio с расширением для PHP — везде переход к интерфейсу происходит. Ну и уж если не PhpStorm использовать, то что тогда? :) Вроде они и так на острие всех актуальных вещей, которые касаются PHP.

Answer 1

[Flying]

Поскольку вопрос не о выполнении кода, а об IDE - то конкретный ответ будет сильно зависеть от того какая IDE используется и даже от того какой framework используется.

По сути вопрос сводится к умению IDE (самостоятельно или через плагины) доставать информацию относящуюся к runtime'у приложения. А это в свою очередь зависит от того умеет ли конкретное приложение (или framework на котором оно построено) предоставлять эту информацию в виде, который умеет понимать IDE. Если да - будет вам счастье перехода на реально используемые реализации, нет - будете переходить на абстрактные интерфейсы и искать реализацию самостоятельно. В целом здесь начинает хорошо помогать привычка прописывать везде типы через аннотации (в вашем примере этого нет), но, конечно, у этого подхода есть свои минусы т.к. необходимо самому следить чтобы указанные типы совпадали с реальными. Здесь в свою очередь помогают ещё несколько хороших привычек связанных с процессом написания кода, но так можно глубоко забраться в offtopic...

В качестве примера приведу пожалуй PHPStorm в связке с плагином Symfony Support в сценарии работы с Symfony. Поскольку в Symfony DI container является компилируемым и, помимо этого, он генерирует машинно-читаемое представление контейнера - через плагин IDE получает кучу информации о том что там в реальности используется в runtime'е и навигация по коду (а также масса других вещей) становится сильно проще.

Но не всем наборам IDE + framework так везёт, к примеру поддержка приложения на ZF2, которым тоже приходится заниматься, такого не предоставляет, приходится искать всё руками. PHPStorm и здесь, конечно, очень выручает, но со сценарием Symfony конечно не сравнить.

Answer 2

[dmitriy]

указывайте конкретику в phpdoc и будет вам счастье

Comments

[Alex_Gerasimov]

Мне кажется в этом случае теряется смысл принципа и при изменении конкретной реализации нужно также будет менять указание во всех phpdoc.

[dmitriy]

да у документации есть минус ее нужно поддерживать.
например у меня есть приложение и я использую Monolog как реализацию psr/log
какая вероятность что в ближайшие 3-5 лет сменю его, очень маловероятно, поэтому можно смело указывать в phpdoc конкретику.
Но опять же я так не делаю потому что есть интерфейс и какая разница что мне прилетает, я точно знаю что контракт будет работать по интерфейсу, внутрянка меня не интересует, а если и нужно я всегда найду ServiceProvider который разруливает зависимости и найду конкретику.