tgoop.com/golang_digest/262
Last Update:
- Оригинал
- Перевод
Хорошая статья о том, почему DI-фреймворки в Go часто создают больше проблем, чем решают.
Вкратце суть статьи:
- DI — это просто передача зависимостей в конструкторы
- Фреймворки типа dig и wire часто пытаются исправить проблемы, которых нет, добавляя лишнюю сложность.
- Самый понятный и надёжный подход для большинства проектов — внедрять зависимости вручную.
————
Я полностью согласен с автором. Чем проще — тем лучше.
Сколько лет работаю с проектами на Go, и DI-фреймворки встречал ровно ноль раз (ну разве что QA себе иногда прикручивали, но им можно).
Что интересно, ни разу не ощущал, что мне без этого плохо. Всё прекрасно работает, всё прозрачно, без магии. Я всегда понимаю, откуда что берётся. Я чётко понимаю откуда что берётся.
Чего ради такие сложности? Чтобы main() был короче? Да он и так не супер большой, и заглядывать туда каждый день не приходится.
Кстати, сравните лучше эту тему объяснил Claude Opus 4. Его вариант выглядит намного проще и понятней, при всём уважении к автору статьи.
В любом случае, статьи от кожаных всё же имеют бОльшую ценность, т.к. передают реальный опыт, а не синтетический.
#article #di
