Каким способом правильнее разрешить зависимости класса?

Question

[Максим Ходырев]

Имеется класс "А" с методом "ab" (и многими другими). Метод "ab" генерирует результат, используя методы нескольких классов, в том числе методы класса "B".

Каким способом правильнее разрешить зависимости метода "ab" от класса "B"?

Какие я вижу способы (на примере Laravel) и их недостатки:

1. Внедрение "B" через конструктор: если класс обрастет зависимостями, каждый раз при создании экземпляра класса будут инстанциироваться все зависимости, что как мне кажется, скажется на быстродействии/потреблении памяти
   
2. Получать зависимость внутри метода, используя сервис-локатор (в случае Laravel это методы resolve, app()->make): при тестировании, для установки заглушек на зависимости, придется тратить много времени на настройку сервис-контейнера.
   
3. Оборачивать пункт 2(получение зависимости через сервис-локатор) в отдельный метод-геттер (например, getMyService()), и при тестировании ставить заглушку на этот геттер: как-таковых недостатков пока не вижу.
   

Как считаете вы?

Comments

[Mishkun]

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

Answer 1

[Алексей Павлов]

4. Передать B аргументом метода ab() (function ab(B $b))

Лучше первый способ. Если класс обрастет зависимостями, тогда можно подумать о рефакторинге. А вдруг не обрастёт?..

Но точнее вам никто не скажет, не посмотрев код - мало данных в тексте вопроса.
1) Как часто вызывается метод ab()? В каждом запросе? или в одном из сотни запросов?
2) используется ли B в других местах класса A?
3) Как передаются зависимости через конструктор?
new A(new B) или $b = new B; new A($b); new A($b); new A($b); или из контейнера? Ведь если B уже есть в контейнере, то передать в конструктор очень просто и быстро.

Comments

[Максим Ходырев]

Передать B аргументом метода ab() (function ab(B $b))

Это не решит проблему. В месте, где будет вызываться ab нужно будет все равно получать зависимость. Таким образом проблема просто перекочует на иерархию выше и пострадает удобство использования. Я не прав?

Лучше первый способ. Если класс обрастет зависимостями, тогда можно подумать о рефакторинге. А вдруг не обрастёт?..

Считайте, что оброс. Какой вариант вы выберете?

Как часто вызывается метод ab()? В каждом запросе? или в одном из сотни запросов?

используется ли B в других местах класса A?

Считайте, что метод вызывается в одном месте, а класс B больше в других методах A не используется, либо количество этих методов стремится к минимуму.

Как передаются зависимости через конструктор?

Речь идет о контейнере. Руками не создаются экземпляры.

Ведь если B уже есть в контейнере, то передать в конструктор очень просто и быстро.

Я рассматриваю крайний случай, считайте что в контейнере еще нет нужного нам экземпляра.

[Алексей Павлов]

>класс B больше в других методах A не используется, либо количество этих методов стремится к минимуму.
так либо не используется, либо используется. Если используется ещё где-то, то я бы точно использовал конструктор. Если только в методе ab(), то я бы подумал всё-таки о передаче через параметр.

>Я рассматриваю крайний случай, считайте что в контейнере еще нет нужного нам экземпляра.
Этот экземпляр из контейнера где-то ещё может использоваться? или только в этом методе ab()?

Ну и самый важный вопрос не ответили - как часто вызывается метод ab()?

[Максим Ходырев]

Как часто вызывается метод ab()? В каждом запросе? или в одном из сотни запросов?

Этот экземпляр из контейнера где-то ещё может использоваться? или только в этом методе ab()?

Во первых, вы задаете слишком много конкретизирующих ситуацию вопросов. Я хотел получить ответ более общий, как например у justpusher. А вы ведете к ответу очень частному. Если бы я знал все детали, я бы не задавал вопросов.
Во вторых, вы в своем анализе двигаетесь по пути "правильнее, значит производительнее". Но я не задавал критерием производительность.

Ваше мнение по вопросу я понял:

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

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

Спасибо за ответ!

Answer 2

[Ширшов Александр]

Тоже всегда использую вариант 1, он гарантирует что у если у вас есть инстанс класса, вы можете его полноценно использовать. Если же использовать мягкие зависимости то возможны ситуации когда объект есть, а зависимости не инициализированы, и ваш класс в некотором смысле становиться либо "зависимым" от фабрики, либо усложняется его использование необходимостью проверки наличия нужных зависимостей. Ведь у зависимостей класса тоже могут быть свои зависимости, у которых может отсутствовать что-то. И чем больше зависимостей, тем сложнее этим управлять.

Так-же большое кол-во аргументов в конструктор является неплохим призывом порефакторить.

Проблемы с памятью решаются сильно дешевле, чем время программистов на поиски ошибок.

Comments

[Максим Ходырев]

Спасибо за ответ!

Answer 3

[justpusher]

Я всегда использую вариант 1.
Чтобы не страдало быстродействие, конструкторы должны быть максимально лёгкими.
Возможно, вы и получите +0.01 секунду и +2МБ памяти, но это не должно вас беспокоить, ведь вы получаете понятный, гибкий и легко тестируемый код.

Comments

[Максим Ходырев]

Согласен с вами, мне тоже 1 вариант нравится больше всех: все явно объявляется и красиво. Однако на практике иногда получается по другому.

Ради интереса спрошу: в каких случаях вы используете(если используете) методы типа resolve?

[Максим Ходырев]

Спасибо за ответ! Вопрос закрываю.

[justpusher]

Максим Ходырев:
в контроллерах и командах, которые точно не будут использоваться повторно. Это типичный подход Symfony.

Некоторые люди высказываются, что в Symfony даже контроллеры должны быть сервисами и не использовать контейнер. Но я считаю, что это лишнее: строго, красиво, но отнимает время и не несёт особой пользы.