VK
Size: a a a
2019 November 02
VK
вот хорошая статья, с выводом которой я согласен. Обычно, фабрик хватает на нужды
SS
А это, про нотификации, не вариант допустим сделать массив делегатов как аналог нотиф.центра ?
SS
Спасибо! Тоже почитаю, но читать уже завтра
VK
А почему допустим не делать DI через конструктор просто?
Какие то примеры swinject были, но там можно было бы статикой решить вроде
Я как бы и минусы зависимостей понимаю и не против хороших либ, но про DI хотелось бы выяснить....на примерах каких то например
Какие то примеры swinject были, но там можно было бы статикой решить вроде
Я как бы и минусы зависимостей понимаю и не против хороших либ, но про DI хотелось бы выяснить....на примерах каких то например
Я обычно и через конструктор и делаю. Используя VIPER (и иже с ними) все зависимости в wireframe (assembly) устанавливаются
VK
нет нормального способа делать инъекции в поля
BB
нет нормального способа делать инъекции в поля
Поддерживаю. Доставка в поля подразумевает форс и не позволяет их скрывать за private. Лучше способе чем конструктор не вижу. ИМХО. Большие массивные init-ы чинятся фабриками или assembly как кому привычнее называть.
V
Поддерживаю. Доставка в поля подразумевает форс и не позволяет их скрывать за private. Лучше способе чем конструктор не вижу. ИМХО. Большие массивные init-ы чинятся фабриками или assembly как кому привычнее называть.
Большие иниты чинятся разделением ответственности
BB
Большие иниты чинятся разделением ответственности
Ну и это тоже конечно же. Наверное в первую очередь. Просто для условного сервиса если нужен:
- логгер
- апи клиент
- репозиторий
- маппер
- toggle провайдер
- и например push нотификейшн манагер
И это нормальная естественная сложность такого класса, а конструктор уже большеват.
- логгер
- апи клиент
- репозиторий
- маппер
- toggle провайдер
- и например push нотификейшн манагер
И это нормальная естественная сложность такого класса, а конструктор уже большеват.
BB
Ответственность разделил, размазал по конкретным классам, но их же теперь какому то фасаду надо доставить? Надо.
VK
Ну и это тоже конечно же. Наверное в первую очередь. Просто для условного сервиса если нужен:
- логгер
- апи клиент
- репозиторий
- маппер
- toggle провайдер
- и например push нотификейшн манагер
И это нормальная естественная сложность такого класса, а конструктор уже большеват.
- логгер
- апи клиент
- репозиторий
- маппер
- toggle провайдер
- и например push нотификейшн манагер
И это нормальная естественная сложность такого класса, а конструктор уже большеват.
Не слишком ли много ответственностей на сервисе?)
BB
ну это условный пример, но есть подобные примеры и реальные
BB
VK
Можно сделать финт ушами, и поместить все поля в структуру и назвать её а-ля
ObjectConfigurationVK
и количество параметров у сервиса резко падает
IL
Подскажите че за беда, отправляю версию а в App Connect не появляется. Ждал минут 30-40...
VK
Также, в ряде случаев можно использовать сервис локаторы
BB
если к примеру взять условный SomeItemDataProvider, который является поставщиком данных о некоторых SomeItem-ах, то через апи клиент он может их получить из апи, замаппить и сохранить в репозиторий, попутно логгировать, так же на основе каких то тогглов менять логику работы и еще и как то слушать работу пуш манагера, чтобы условно обновлять что-то. Пример от балды конечно, но впонле все по полочкам.