IG
я не до конца понимаю, какие проблемы решает или какие преимущества дает такой подход, можете поделиться?
Именно подход как у Евгения, или в целом разделение на feature-api и feature-impl?
Size: a a a
2018 September 05
AK
Как у Евгения
IG
Как у Евгения
Перечитал короче, и в итоге понял что ничего не понял 🙂
IG
@eugene_matsyuk в чём принципиальное различие между твоим подходом и просто схемой
app -> feature-api -> feature-impl ?
Какие преимущества?
app -> feature-api -> feature-impl ?
Какие преимущества?
IG
@eugene_matsyuk
У тебя я так понимаю что-то подобное?
———> feature-api
/ ^
app ——> feature-adapter |
\ |
———> feature-impl
У тебя я так понимаю что-то подобное?
———> feature-api
/ ^
app ——> feature-adapter |
\ |
———> feature-impl
AK
вот и я о том же
AK
но это сейчас, и если в дальнейшем вместо адаптера мержем будет заниматься app, то я вообще теряюсь для чего это все
IG
Ааа, я походу понял.
feature-impl не может заимплементить feature-api не завися от него. И получается циклическая зависимость
feature-impl не может заимплементить feature-api не завися от него. И получается циклическая зависимость
IG
То есть схема app -> feature-api -> feature-impl невозможна в принципе
IG
ну либо внутри feature-api так или иначе придётся писать какие-то врапперы над feature-impl которые имплементят api
AK
ну не циклическая
AK
api не надо зависить от impl
IG
тогда у тебя app будет зависеть и от api и от impl
IG
а вся суть этого подхода как раз избавиться от зависимости от impl
IG
(от impl)
AK
тогда добавиться модуль который выше написан как adapter
IG
IG
только в случае с одним модулем - кода будет больше чем в случае с отдельным адаптером
IG
т.к. если есть отдельно adapter то мы можем зависеть от feature-api в feature-impl и не париться созданием врапперов, а просто имплементить интерфейсы из api
AK