Является ли хорошей практикой неявная зависимость без наследования с целью избавиться от дублирования инстансов?

Question

[Алексей Николаев]

Доброго дня.
Не хочу штамповать инстансы гипотетического класса Depend (например, вычисления при создании инстанса), при этом необходимо, чтобы в нем был доступ к классу Vendor. При этом, инстанс класса Vendor должен быть один на систему, но он не должен быть синглтоном. Vendor используется в нескольких классах, и прежде всего в точке входа - классе Main.

Наследовать Depend от Main избыточно - ведь по смыслу Depend не является зависимым от содержимого Main (кроме свойства, хранящего в себе инстанс Vendor, но наследование не для этого). Придумал такую схему, в которой доступ ко всем так или иначе зависимым классам осуществляется через точку входа (или контейнер с зависимостями, если создать еще один слой), которая передается зависимым классам, чтобы они (зависимые классы) могли получить уже созданный ранее инстанс.

class Main {
    public $Vendor;

    private $Depend;

    public function __construct() {
        $this->Vendor = new Vendor;
        $this->Depend = new Depend($this);
    }
}

class Depend {
    private $Vendor;

    public function __construct(Main $Container) {
        $this->Vendor = $Container->Vendor;
    }
}

class Vendor {
    public function __construct() {}
}

Насколько данное решение хорошо? Не является ли такой подход антипаттерном? Есть ли лучшие альтернативы?

Заранее спасибо.

Answer 1

[dev400]

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

Я у себя в проекте реализовал такую штуку

/**
     * AccountController constructor.
     * @param ViewInterface $view
     * @param ModelInterface $model
     * @param AuthHandler $authHandler
     * @Dependencies(
     *   'app\Core\View\BaseView',
     *   'src\Models\Auth\AuthModel',
     *   'src\Middleware\Auth\AuthHandler'
     * )
     */
    public function __construct(ViewInterface $view,ModelInterface $model, AuthHandler $authHandler) {

        $this->view = $view;
        $this->model = $model;
        $this->authHandler = $authHandler;

    }

В аннотациях перечисляю зависимости класса, парсер вытаскивает нужные зависимости и кладет в конструктор.

Comments

[dmitriy]

зачем писать когда есть container.thephpleague.com/auto-wiring

[dev400]

diamond: как эта штука будет работать с интерфейсами?

[dmitriy]

так подождите а какая роль интерфейсов у вас, ведь всегда на вход будет идти один и тот же объект, указанный в @Dependencies . Получается это равносильно __construct(\app\Core\View\BaseView $view,....)
с container auto-wiring

[dev400]

diamond: в @Dependencies можно сменить класс на любой, который имплементирует интерфейс, который ожидается в аргумертах

[dmitriy]

но вы ведь меняете прямо в docblock комментарии класса соответственно на вход всегда идет один и тот же класс

[dev400]

diamond: да, php по другому не умеет :)

[dmitriy]

я имею ввиду что если вы пишите например библиотеку которая может на вход принимать объекты разных классов но должны соблюдать определенный контракт:
class Parser{
function __construct(LoggerInterface $logger){}
$parser = new Parser(new MyLogger);
или
$parser = new Parser(new Monolog\Logger("default"));

но в вашем случае вы работает с контроллерами который на вход берут уже конкретные классы

[dmitriy]

container от thephpleague как и ваш способ работает на рефлексии так что разницы особо нет, единственно что container thephpleague использует такие чтуки как Inflectors, Service Providers которые тоже могут быть полезны. Ну и он идет по дефолту в Laravel

[dev400]

diamond: до ларавел пока не дошел, начал изучать фреймворки с yii2. обязательно попробую этот автовайринг подключить