AD
Кстати, прикольно
обычный здоровый инжект в конструктор, контейнер здесь только для того, чтобы все зависимости в кучу собрать
Size: a a a
2020 September 23
2020 September 24
S
Я правильно понимаю, интерактор общяется с репозиторием без знания какая это репа
AD
с хрена ли?
A
с хрена ли?
перевод - в котлин есть интерфейсы )
QH
а ты в курсе, что такое интерфейсы, а что такое анонимные классы?
S
а ты в курсе, что такое интерфейсы, а что такое анонимные классы?
Да
QH
Singular
Да
и что же?
S
и что же?
сам задал вопрос, сам и ответил)
S
Singular
Я правильно понимаю, интерактор общяется с репозиторием без знания какая это репа
а что насчет этого?
D
Singular
Я правильно понимаю, интерактор общяется с репозиторием без знания какая это репа
Все правильно понимаешь. Нет необходимости узнавать, что это за репозиторий. В этом фишка )
GK
А кто не даёт все зависимости через конструктор провайдить?)
Слои абсолютно не меняются
Слои абсолютно не меняются
У нас в продакшн как раз такой подход и используется. DI-фреймворки слишком расслабляют и разрабы начинают их использовать направо и налево, без разбору, ломая структуру. Использование стандартных средств ООП, без монстрофреймворков, создает более строгую, SOLIDную и более простую структуру кода. Да и компилится такой проект быстрее.
GK
Вот тут как раз этот пример детально смотрят
https://www.pragmaticobjects.com/chapters/007_di_containers.html
https://www.pragmaticobjects.com/chapters/007_di_containers.html
IN
Так, не, давай по делу. Di-либы ломают солид, а писать самопальные штуки - это другое
Простите можно подробней. Как именно они ломают солид?)
AV
Di - это способ достижения буквы D из SOLID
Это инструмент, довольно мощный. Как и любой другой его можно использовать неправильно, но Di не ломает SOLID)
Это инструмент, довольно мощный. Как и любой другой его можно использовать неправильно, но Di не ломает SOLID)
RC
Ilya Nikolaev
Простите можно подробней. Как именно они ломают солид?)
Вот тут был пример. Штука именно в реализации, а не в принципе. Опять же, немного выше по сообщениям от этого момента есть пример, как обойти такое, это да
NT
Вот тут был пример. Штука именно в реализации, а не в принципе. Опять же, немного выше по сообщениям от этого момента есть пример, как обойти такое, это да
Сори, возможно что-то упускаю, но почему бы в примере из статьи не заинжектить фабрику, которая уже в рантайме будет решать какую из реализаций бинов отдавать?
ИМ
Подскажите кто-то по ооп: какие преимущества даёт нам создание абстракции/интерфейса и имплементации, а в классах-клиентах предоставление зависимостей от абстракции? Одно из преимуществ насколько я знаю это упрощение тестирования, но разве с этим не справляется мокито?
ИМ
Один из примеров, может кто смотрел, чистую архитектуру резо кодера. Там в домейн слое интерфейсы, а в слое данных реализации. Но пока что я это реализовал как тупое следование примеру, кто-то разобрался в плюшках?
ИМ
Один из примеров, может кто смотрел, чистую архитектуру резо кодера. Там в домейн слое интерфейсы, а в слое данных реализации. Но пока что я это реализовал как тупое следование примеру, кто-то разобрался в плюшках?
тут вряд-ли кто-то смотрел, но сути не меняет
RC
Сори, возможно что-то упускаю, но почему бы в примере из статьи не заинжектить фабрику, которая уже в рантайме будет решать какую из реализаций бинов отдавать?
Тоже вариант. В тестах мокать лишнее придется, а так - да. Ну и еще мое субьективное - хочется не фабрики везде носить за собой, а реальные зависимости)