В данной статье рассматривается использование специализированного модуля Dagger 2 под android и подразумевается, что у вас есть наличие базовых знаний по Dagger 2.
В Dagger 2.10 был представлен новый модуль специально для Android. Данный модуль поставляется как дополнение, состоящий из дополнительной библиотеки и компилятора.
В версии 2.11 были некоторые небольшие изменения, в частности некоторые классы, были переименованы, поэтому будет использоваться именно эта версия.
На хабре уже было несколько хороших статей по установке и работе с Dagger 2:
Я же хочу поделиться своим опытом использования Dagger 2 на реальных проектах с реальными кейсами. Раскрыть читателю мощь и удобство как самого Dagger’а, так и такого его аспекта, как Subcomponent.
Перед тем, как пройти под кат, следует ознакомиться с вышеуказанными статьями.
Кого заинтересовал, you are welcome!
Перевод статьи Field Dependency Injection Considered Harmful за авторством Vojtech Ruzicka
Внедрение зависимостей через поля является очень популярной практикой в DI-фреймворках, таких как Spring. Тем не менее, у этого метода есть несколько серьезных компромиссов и поэтому стоит чаще избегать его.
Читать полностью »
Laravel имеет мощный IoC-контейнер, но, к сожалению, официальная документация Laravel не описывает все его возможности. Я решил изучить его и задокументировать для собственного использования.
Примеры в данной статье основаны на Laravel 5.4.26, другие версии могут отличаться.
Я не буду объяснять, что такое DI и IoC в этой статье — если вы не знакомы с этими принципами, вы можете прочитать статью "What is Dependency Injection?" от Fabien Potencier (создателя фреймворка Symfony).Читать полностью »
Библиотека EasyDi содержит контейнер зависимостей для Swift. Синтаксис этой библиотеки был специально разработан для быстрого освоения и эффективного использования. Она умещается в 200 строк, при этом умеет все, что нужно взрослой Di библиотеке:
— Создание объектов и внедрение зависимостей в существующие
— Разделение на контейнеры — Assemblies
— Типы разрешения зависимостей: граф объектов, синглетон, прототип
— Разрешение циклических зависимостей
— Подмена объектов и конктесты зависимостей для тестов
В EasyDi нет разделения на register/resolve. Вместо этого зависимости описываются вот так:
var apiClient: IAPIClient {
return define(init: APIClient()) {
$0.baseURl = self.baseURL
}
}
Cocoapods / EasyDi
Github / EasyDi
Под катом очень краткое описание «Зачем DI и что это», также примеры использования библиотеки:
В этой заметке мне хотелось бы поделиться информацией о небольшом, но, на мой взгляд, весьма и весьма полезном проекте, в котором Stefán Jökull Sigurðarson добавляет все известные ему IoC контейнеры, которые мигрировали на .NET Core, и с использованием BenchmarkDotNet проводит замеры instance resolving performance. Не упустил возможности поучавствовать в этом соревновании и я со своим маленьким проектом FsContainer.
Есть своя «внешняя» библиотека и есть своё приложение, использующее эту библиотеку (подгружается через внешний репозитарий). Требуется внести изменение и в библиотеку и в приложение.
Казалось бы, собери библиотеку и выложи её в локальный maven-репозитарий, а потом уже собирай приложение. Но хочется, чтобы можно было поправив код в библиотеке сразу попробовать изменения в приложении и при этом сохранить раздельное хранение кода библиотеки и приложения, включая настройки IDE и прочее.
С помощью gradle и и символических связей в файловой системе такое можно легко устроить.
Читать полностью »
Добрый день, коллеги!
На YiiConf пришло много заявок — 12 докладов и 2 мастер-класса. Впервые на одной конференции будут выступать сразу четыре разработчика из Yii core team.
Мне нравится использовать композицию и инъекцию зависимостей, но когда каждая сущность начинает инъектится несколькими зависимости, получается некое нагромождение.
Проект растет и приходится инъектить все больше зависимостей в объекты, рефакторить методы помногу раз, Xcode не особо с этим помогает, как мы знаем.
Но есть более управляемый способ.
Помнится, во времена .NET 1.1 и 2.0 можно было часто увидеть пророчества майкрософтовских евангелистов, мол, скоро любая домохозяйка сможет создавать сайты и писать программы. Большинство программистов посмеялось, но, как выяснилось, кто-то отнёсся к этому серьёзно. Во всяком случае, это объясняет, почему шаблоны проектирования IoC/DI получили второе дыхание в 2000-х, причём даже внутри самой MS (желаю Вам никогда в жизни не столкнуться с SCSF).
С точки зрения теории разработки ПО лично мне гораздо чаще приходилось читать или слышать хвалебные статьи и отзывы об IoC/DI, но, как всегда, критика тоже есть. Можно ознакомиться, например, здесь (англ.), здесь (англ.), тут (хабр), ещё (англ.). В частности в вину ставится нарушение принципа инкапсуляции в ООП.
Читать полностью »