Zenject (Extenject) в Unity: Исчерпывающее руководство по внедрению зависимостей
Представьте: Вы добавляете новую механику, а игра ломается в пяти местах. Вы тратите часы на поиск того самого скрипта, который неожиданно зависит от ваших изменений. Знакомо? Zenject ( Extenject ) решает это раз и навсегда. Эта статья о том, что такое zenject и как им пользоваться.
https://habr.com/ru/articles/919846/
#Zenject #Unity #c# #тестирование #разработка_игр #di #внедрение_зависимостей
[Перевод] Вероятно, вам не нужен DI-фреймворк
Я считаю, что при работе с Go в контексте нашей отрасли внедрение зависимостей (dependency injection, DI) часто имеет плохую репутацию из-за DI-фреймворков . Но сама по себе DI как техника довольно полезна. Просто её объясняют слишком большим количеством ОО-жаргона, что приводит к ПТСР у тех, кто перешёл на Go, чтобы сбежать из культа банды четырёх.
https://habr.com/ru/articles/914876/
#внедрение_зависимостей #dependency_injection #di #зависимости #wire #dig
Еще раз про Di-контейнеры в golang
В предыдущей статье я попросил — « Расскажите, зачем вам DI‑контейнер в golang ». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода . Получается, мы все таки «тащим» Di‑контейнер в проект . Ну, хорошо.... Вероятно, это будет uber‑fx , ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»? Мой ответ — нет, uber‑fx не «тащим» , потому что можно еще проще и понятнее . Делаем...
Расскажите, зачем вам DI-контейнер в golang
Я много писал на PHP + Symfony, писал на Angular, Vue. Я понимаю зачем DI-контейнер в Symfony, могу понять зачем он на фронте, особенно PWA. Я понимаю, какую проблему/задачу он там решает, почему он там нужен. Но никак не могу понять, зачем он в микросервисах и даже сервисах большого размера на Go. И вот почему... Так почему же
Дирижируем зависимостями: Оркестрация Koin scopes в Jetpack Compose Navigation
Привет, Хабр! Меня зовут Артем и я автор и ведущий YouTube и Telegram каналов Android Insights. В этой статье я рассмотрю, как использовать Koin scopes в связке с Jetpack Compose Navigation, чтобы эффективно управлять зависимостями на разных уровнях навигационного графа.
https://habr.com/ru/articles/881982/
#android #kotlin #koin #di #внедрение_зависимостей #scope #dependency_injection
Путаясь в замыканиях
В комментах к статье " Синглтон - корень всех зол ", который вообще-то про паттерн проектирования, я высказал мысль, что в функциональном программировании " все функции - синглтоны " (это уже в смысле lifestyle - больше одной функции на приложение не нужно). Тут же мне более опытные коллеги насовали в панамку, что " функции не синглтоны, потому что существуют замыкания ". Я, конечно, " сварщик не настоящий " - в ФП серьёзно никогда не игрался, но основные идеи вроде как у всех на слуху: неизменяемость данных, чистота функций, функция как аргумент / результат другой функции. На мой субъективный взгляд, при таких вводных, нет никаких доводов за то, чтобы в приложении иметь более одного экземпляра чистой функции. Какой смысл иметь два экземпляра функции, если она не имеет побочных эффектов - для одних и тех же входных данных всегда возвращает один и тот же результат, вне зависимости от внешних условий? Ну? Вот и я думаю, что никакого. Тем не менее, мысль про замыкания надо было как-то подумать - не, ну а вдруг?! Под катом я привожу результаты своих изысканий на примере очень простого функционала на JS, написанного в трёх разных стилях.
https://habr.com/ru/articles/875608/
#фунциональное_программирование #процедурное_программирование #замыкания #шаблоны_проектирования #внедрение_зависимостей #ооп
[Перевод] Как спроектировать библиотеку для Spring Boot
Принцип DRY (Не повторяйся) – это важная составляющая цикла разработки программного обеспечения. Его цель – избежать ненужной повторяемости в коде. В частности, имеется множество приложений, которые могут находиться в составе одной и той же микросервисной архитектуры и использовать один и тот же компонент. В результате код становится неудобно поддерживать, поскольку всякий раз, когда требуется внести изменение в этот компонент, с каждым из этих приложений приходится разбираться отдельно. В этой статье давайте рассмотрим, как можно вынести такие компоненты из приложений в отдельный модуль. Тем самым мы одновременно стремимся упростить поддержку кода и сократить в нём количество повторов .
Habr
