mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Server stats:

8.8K
active users

#внедрение_зависимостей

0 posts0 participants0 posts today
Habr<p>Еще раз про Di-контейнеры в golang</p><p>В предыдущей статье я попросил — « Расскажите, зачем вам DI‑контейнер в golang ». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода . Получается, мы все таки «тащим» Di‑контейнер в проект . Ну, хорошо.... Вероятно, это будет uber‑fx , ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»? Мой ответ — нет, uber‑fx не «тащим» , потому что можно еще проще и понятнее . Делаем...</p><p><a href="https://habr.com/ru/articles/903300/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">habr.com/ru/articles/903300/</span><span class="invisible"></span></a></p><p><a href="https://zhub.link/tags/%D0%B2%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>внедрение_зависимостей</span></a> <a href="https://zhub.link/tags/%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>архитектура</span></a> <a href="https://zhub.link/tags/golang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>golang</span></a> <a href="https://zhub.link/tags/%D1%80%D0%B5%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>рефакторинг</span></a></p>
Habr<p>Расскажите, зачем вам DI-контейнер в golang</p><p>Я много писал на PHP + Symfony, писал на Angular, Vue. Я понимаю зачем DI-контейнер в Symfony, могу понять зачем он на фронте, особенно PWA. Я понимаю, какую проблему/задачу он там решает, почему он там нужен. Но никак не могу понять, зачем он в микросервисах и даже сервисах большого размера на Go. И вот почему... Так почему же</p><p><a href="https://habr.com/ru/articles/898290/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">habr.com/ru/articles/898290/</span><span class="invisible"></span></a></p><p><a href="https://zhub.link/tags/golang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>golang</span></a> <a href="https://zhub.link/tags/%D0%B2%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>внедрение_зависимостей</span></a> <a href="https://zhub.link/tags/%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>архитектура</span></a></p>
Habr<p>Дирижируем зависимостями: Оркестрация Koin scopes в Jetpack Compose Navigation</p><p>Привет, Хабр! Меня зовут Артем и я автор и ведущий YouTube и Telegram каналов Android Insights. В этой статье я рассмотрю, как использовать Koin scopes в связке с Jetpack Compose Navigation, чтобы эффективно управлять зависимостями на разных уровнях навигационного графа.</p><p><a href="https://habr.com/ru/articles/881982/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">habr.com/ru/articles/881982/</span><span class="invisible"></span></a></p><p><a href="https://zhub.link/tags/android" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>android</span></a> <a href="https://zhub.link/tags/kotlin" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>kotlin</span></a> <a href="https://zhub.link/tags/koin" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>koin</span></a> <a href="https://zhub.link/tags/di" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>di</span></a> <a href="https://zhub.link/tags/%D0%B2%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>внедрение_зависимостей</span></a> <a href="https://zhub.link/tags/scope" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>scope</span></a> <a href="https://zhub.link/tags/dependency_injection" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>dependency_injection</span></a></p>
Habr<p>Путаясь в замыканиях</p><p>В комментах к статье " Синглтон - корень всех зол ", который вообще-то про паттерн проектирования, я высказал мысль, что в функциональном программировании " все функции - синглтоны " (это уже в смысле lifestyle - больше одной функции на приложение не нужно). Тут же мне более опытные коллеги насовали в панамку, что " функции не синглтоны, потому что существуют замыкания ". Я, конечно, " сварщик не настоящий " - в ФП серьёзно никогда не игрался, но основные идеи вроде как у всех на слуху: неизменяемость данных, чистота функций, функция как аргумент / результат другой функции. На мой субъективный взгляд, при таких вводных, нет никаких доводов за то, чтобы в приложении иметь более одного экземпляра чистой функции. Какой смысл иметь два экземпляра функции, если она не имеет побочных эффектов - для одних и тех же входных данных всегда возвращает один и тот же результат, вне зависимости от внешних условий? Ну? Вот и я думаю, что никакого. Тем не менее, мысль про замыкания надо было как-то подумать - не, ну а вдруг?! Под катом я привожу результаты своих изысканий на примере очень простого функционала на JS, написанного в трёх разных стилях.</p><p><a href="https://habr.com/ru/articles/875608/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">habr.com/ru/articles/875608/</span><span class="invisible"></span></a></p><p><a href="https://zhub.link/tags/%D1%84%D1%83%D0%BD%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>фунциональное_программирование</span></a> <a href="https://zhub.link/tags/%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%B4%D1%83%D1%80%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>процедурное_программирование</span></a> <a href="https://zhub.link/tags/%D0%B7%D0%B0%D0%BC%D1%8B%D0%BA%D0%B0%D0%BD%D0%B8%D1%8F" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>замыкания</span></a> <a href="https://zhub.link/tags/%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D1%8B_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>шаблоны_проектирования</span></a> <a href="https://zhub.link/tags/%D0%B2%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>внедрение_зависимостей</span></a> <a href="https://zhub.link/tags/%D0%BE%D0%BE%D0%BF" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ооп</span></a></p>
Habr<p>[Перевод] Как спроектировать библиотеку для Spring Boot</p><p>Принцип DRY (Не повторяйся) – это важная составляющая цикла разработки программного обеспечения. Его цель – избежать ненужной повторяемости в коде. В частности, имеется множество приложений, которые могут находиться в составе одной и той же микросервисной архитектуры и использовать один и тот же компонент. В результате код становится неудобно поддерживать, поскольку всякий раз, когда требуется внести изменение в этот компонент, с каждым из этих приложений приходится разбираться отдельно. В этой статье давайте рассмотрим, как можно вынести такие компоненты из приложений в отдельный модуль. Тем самым мы одновременно стремимся упростить поддержку кода и сократить в нём количество повторов .</p><p><a href="https://habr.com/ru/companies/piter/articles/850820/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">habr.com/ru/companies/piter/ar</span><span class="invisible">ticles/850820/</span></a></p><p><a href="https://zhub.link/tags/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>перевод</span></a> <a href="https://zhub.link/tags/spring_boot" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>spring_boot</span></a> <a href="https://zhub.link/tags/%D0%B2%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>внедрение_зависимостей</span></a></p>