TK
это значит что надо явно super вызывать в контрукторе?
Size: a a a
2020 March 27
RV
Всегда так было
АА
нашел. он автоматически вызывает суперконструктор, даже без super
If you don’t explicitly call a superconstructor, a constructor will call the default, no-arg constructor of its superclass.
If you don’t explicitly call a superconstructor, a constructor will call the default, no-arg constructor of its superclass.
DS
>Важное дополнение : Производные классы не наследуют конструкторы от родительских классов
как это понимать?
как это понимать?
так, что конструкторы не наследуются?
А
есть те, кто использует clean architecture? можете подсказать в чём принципиальная разница между usecase и repository?
🌶
Можно ли использовать одну базу данных для части приложения, написанного на js и встроенного в flutter в виде webview и для части приложения, написанного на flutter (базовая часть)?
А
Можно ли использовать одну базу данных для части приложения, написанного на js и встроенного в flutter в виде webview и для части приложения, написанного на flutter (базовая часть)?
если только через rest api
IK
>Важное дополнение : Производные классы не наследуют конструкторы от родительских классов
как это понимать?
как это понимать?
Ка отказ от ООП;)
DO
Андрей
есть те, кто использует clean architecture? можете подсказать в чём принципиальная разница между usecase и repository?
repository - это фасад над получением данных. Он получает данные из источника (http, db) и мапит их в доменные модели.
а usecase - бизнес логика. В мобилках они часто выглядят как прокси в репозиторий)
а usecase - бизнес логика. В мобилках они часто выглядят как прокси в репозиторий)
А
repository - это фасад над получением данных. Он получает данные из источника (http, db) и мапит их в доменные модели.
а usecase - бизнес логика. В мобилках они часто выглядят как прокси в репозиторий)
а usecase - бизнес логика. В мобилках они часто выглядят как прокси в репозиторий)
Не смотрел курс от Reso Coder? Просто он там использует datasource -> repository -> usecase для получения данных, вот мне показался один шаг излишним
DO
ну репозиторий вот объединяет датасорсы
А
ну репозиторий вот объединяет датасорсы
ну это понятно, он, по сути, как раз и может отдавать данные, зачем использовать usecase как обёртку над репозиторием?
DS
Андрей
Не смотрел курс от Reso Coder? Просто он там использует datasource -> repository -> usecase для получения данных, вот мне показался один шаг излишним
потмому что репозиторий это интерфейс, а его реализация находится уже в data слое, которая ну никак не должна быть связана с ui слоем
DS
и между use case и ui должен быть презентер раз уж на то пошло
А
потмому что репозиторий это интерфейс, а его реализация находится уже в data слое, которая ну никак не должна быть связана с ui слоем
т.е. usecase уже используется для связи с интерфейсом?
DS
api->repositoryImpl->repository(dependency invertion)-> usecase-> presenter-> ui
DS
Андрей
т.е. usecase уже используется для связи с интерфейсом?
юзкейс должен работать с интерфейсом репозитория
T
это MVP?
А
а можно поподробнее про presenter, что это, state management (bloc, например)?
DS
это MVP?
это не архитектура, а только подход чтобы связать данные с ui