Задать вопрос
vitaly_74
@vitaly_74

DI как правильно внедрять «постоянные зависимости»?

Программирую на php потому пишу именно в этой теме, поскольку реализация внедрения DI в разных языках разная (например решения в java мне не подходят).
К самому вопросу:
Что если класс на вход будет постоянно принимать один и тот же класс, который в свою очередь тоже завсим от какого то объекта, а тот в свою очередь от третьего.
Появляется вопрос: Как быстро все это конструировать не используя DI - контейнеры?
Разумно ли устанавливать все стандартные зависимости в конструкторе объекта?
Или в объекте по сути вообще не должно быть new?
Приведу пример: когда делаем запрос за списком статей то вызываем примерно следующее:
$connection = new Connection('db_test'); //допустим что db_test - основная база.
$db = new Db($connection);
$post = new Post($db);
echo $post->count();

разумно ли будет писать всю эту цепочку в конструкторе?
т.е.
class Post{
   __construct(){
      $connection = new Connection('db_test'); //допустим что db_test - основная база.
      $this->db = new Db($connection);
   }
}


мне кажется это не разумно. С другой стороны классы Connection + Db - постоянны и не меняются по сути своей. Также мне не хотелось бы писать DI контейнер для каждого "серьезного" класса.
может подскажите где разумней всего писать new (т.е. создавать новые объекты).
Если рассматривать конкретную архитектуру mvc
тот тут ответом бы могло послужить - писать все new в контроллере. Но тоже сомневаюсь. Помогите мне пожалуйста.
  • Вопрос задан
  • 107 просмотров
Подписаться 1 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 4
Согласно принципам SOLID, где буковка D — принцип инверсии зависимостей, так делать нельзя. Принцип сформулирован так:
  • Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
  • Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Т.е. в вашем случае никаких new Connection и new Db в конструкторе класса Post быть не должно. Вы же не собираетесь создавать коннект к БД в каждом классе? В посте, в комментарии, в пользователе?
Ответ написан
mad_maximus
@mad_maximus

Также мне не хотелось бы писать DI контейнер для каждого "серьезного" класса.


Контейнер пишется один раз и работает всегда с любыми зависимости. Вероятно, вы ещё не поняли преимущества контейнера. Благодаря нему вы можете менять зависимости налету, не изменяя код классов.
Ответ написан
puchkovk
@puchkovk
Усложнять — просто. Упрощать — сложно.
Как быстро все это конструировать не используя DI - контейнеры?


Ответ - если вы хотите писать приличный код, то никак. Извернуться можно по-разному, но в итоге у вас все равно получится подобие DI контейнера. Круглое - лучше катить. Поэтому проще сразу взять DI контейнер. Рядом в ответах уже подсказали неплохой вариант (League). С ним не так сложно разобраться, просто надо понять базовый принцип.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы