Эшу быдлокодит

Dependency injection (DI).

В процессе написания сборщика я осознал логику современного подхода к проектированию приложений: использования внедрения зависимостей (DI).

Ранее я многократно использовал этот подход для подключения готовых компонентов из ASP. Net Core. Но как-то не задумывался о сути подхода, лежащего в основе.

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

Внедрение зависимостей - шажок в сторону декларативного программирования: мы описываем взаимоотношения элементов программы друг с другом, после чего регистрируем эти элементы, указывая их жизненный цикл.

После попадания в точку входа, CLR соберёт все необходимые для работы элементы, в идеале нам не придется самим ни создавать, ни удалять классы.

Элементы программы - сервисы - могут иметь один из четырех вариантов жизненного цикла:
1. Transient. Каждый раз когда есть необходимость в экземпляре класса будет создан новый экземпляр, а по выполнении работы - удален.
2. Scoped. Один экземпляр класса на одну порождающую причину.
3. Singleton. На веки будет лишь один экземпляр класса, с ним и работайте. CLR проследит за его единственностью, если использовать его только через DI.
4. Hosted Service. В отличие от первых трёх видов, создаваемых "по пинку" из внешнего мира, создаётся сразу при старте приложения. Обычно выполняет какую-то постоянную/периодическую работу, в остальном - как Singleton.

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

Преимущества использования внедрения зависимостей:
1. Программа превращается
в конструктор, можно
многократно и без мучений переиспользовать удачный код, вынеся его в библиотеки и подключая по мере необходимости.
2. Исключается часть ошибок по невнимательности: нельзя забыть создать класс или создать его с неверными параметрами. В обычном случае проблема может всплыть нескоро и вызвать много затруднений. А в случае с DI программа завалится на старте и сообщит, где и чего ей не хватает для счастья.
3. Удобство тестирования и разработки "по частям". Можно прямо со старта накидать архитектуру, понатыкав заглушек. И реализовывать их постепенно, меняя одно слово при регистрации класса. Также удобно покрывать тестами отдельные сервисы.

Недостатки:
1. Логика приложения становится труднее в восприятии посторонним человеком: что делает каждый сервис понятно, а вот что они делают вместе - уже не всегда.
2. Написание тестов, которые реально что-то проверяют, хоть и становится намного проще, но при этом и более трудоемким, требуя больше кода на заглушки и моки.

В целом, подход мне очень зашёл, пока не разочаровался в нем, внедряю его везде где это получается сделать быстро и просто.

P.S. Внедрение зависимостей есть и для питона.

#кодинг

Хабр

Внедрение зависимостей the Python way

Зачем нужно внедрение зависимостей? Оно уменьшает связанность компонентов в приложение и упрощает тестирование. У некоторых разработчиков есть мнение, что внедрение зависимостей нужно только в...

www.tg-me.com/us/Эшу быдлокодит/com.eshu_coding/197

267 viewsEshu Marabo, edited  May 10, 2021 at 16:32

Dependency injection (DI).

В процессе написания сборщика я осознал логику современного подхода к проектированию приложений: использования внедрения зависимостей (DI).

Ранее я многократно использовал этот подход для подключения готовых компонентов из ASP. Net Core. Но как-то не задумывался о сути подхода, лежащего в основе.

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

Внедрение зависимостей - шажок в сторону декларативного программирования: мы описываем взаимоотношения элементов программы друг с другом, после чего регистрируем эти элементы, указывая их жизненный цикл.

После попадания в точку входа, CLR соберёт все необходимые для работы элементы, в идеале нам не придется самим ни создавать, ни удалять классы.

Элементы программы - сервисы - могут иметь один из четырех вариантов жизненного цикла:
1. Transient. Каждый раз когда есть необходимость в экземпляре класса будет создан новый экземпляр, а по выполнении работы - удален.
2. Scoped. Один экземпляр класса на одну порождающую причину.
3. Singleton. На веки будет лишь один экземпляр класса, с ним и работайте. CLR проследит за его единственностью, если использовать его только через DI.
4. Hosted Service. В отличие от первых трёх видов, создаваемых "по пинку" из внешнего мира, создаётся сразу при старте приложения. Обычно выполняет какую-то постоянную/периодическую работу, в остальном - как Singleton.

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

Преимущества использования внедрения зависимостей:
1. Программа превращается
в конструктор, можно
многократно и без мучений переиспользовать удачный код, вынеся его в библиотеки и подключая по мере необходимости.
2. Исключается часть ошибок по невнимательности: нельзя забыть создать класс или создать его с неверными параметрами. В обычном случае проблема может всплыть нескоро и вызвать много затруднений. А в случае с DI программа завалится на старте и сообщит, где и чего ей не хватает для счастья.
3. Удобство тестирования и разработки "по частям". Можно прямо со старта накидать архитектуру, понатыкав заглушек. И реализовывать их постепенно, меняя одно слово при регистрации класса. Также удобно покрывать тестами отдельные сервисы.

Недостатки:
1. Логика приложения становится труднее в восприятии посторонним человеком: что делает каждый сервис понятно, а вот что они делают вместе - уже не всегда.
2. Написание тестов, которые реально что-то проверяют, хоть и становится намного проще, но при этом и более трудоемким, требуя больше кода на заглушки и моки.

В целом, подход мне очень зашёл, пока не разочаровался в нем, внедряю его везде где это получается сделать быстро и просто.

P.S. Внедрение зависимостей есть и для питона.

#кодинг

BY Эшу быдлокодит