Dev Easy Notes

Закончим срач, про интерфейсы. Из всех аргументов "за", был только один связанный с практикой. Комент про то, как интерфейсы помогли разработчику перевести свой проект на KMP в краткие сроки.

Однако я считаю, что этот аргумент совершенно не относится к пользе интерфесов. Интерфейсы не дают существенных преимуществ при миграции на KMP, и объём работы остаётся примерно таким же. Поразгоняем эту мысль.

Рассмотрим типичное Android-приложение. Представим, что оно свежее и сразу разрабатывалось на Compose и корутинах. Уже только это решает значительную часть проблем при переходе на KMP. Cтандартный технологический стек для мобилки:

👉 Retrofit + OkHttp для сетевого взаимодействия
👉 Room для работы с БД (если оно вообще нужно)
👉 MVI для презентационного слоя (они уже все на базе корутин)
👉 Timber для логирования
👉 Dagger для внедрения зависимостей

Приложение мы пишем без лишних интерфейсов: Interactor, Presenter и даже Repository всегда просто классы. При условии что реализация только одна, если несколько, то разумеется делаем интерфейс.

Для переезда на KMP нам нужно два основных шага: перевести стек для сети и БД на мультиплатформу и вынести за интерфейсы платформенные компоненты (даты, UUID и подобное). Последнее заранее никто не выносит, если только не закладывали перенос заранее, поэтому в любом случае придется делать.

📞 Сеть. Retrofit изначально требует использования интерфейсов, поэтому эта часть уже готова. Мы просто то меняем зависимость на Ktorfit и заменяем OkHttp на Ktor. Возможно потребуется переписать интеракторы, но вы бы в любом случае их переписывали.

💽 БД. Если ее на проекте нет, то вы уже сделали 90% работы. Если же есть, то Room последней версии уже мультиплатформенная. Если же Room не нравится, то придется мигрировать на SQLDelight. Как бы вы не закрывались интерфейсами, у вас все равно будет дофига работы по мигрированию сущностей на другую либу. Все равно менять код Repository, поэтому профит интерфейса не ясен.

💉 DI. Если у вас был Dagger или Hilt или Anvil – вы в заднице. Теперь вам нужно или делать кастомный DI или переходить на Koin. Кстати если шарите, в комментариях подскажите, какие еще DI контейнеры мультиплатформенные?

📜 Логер. Никто никогда не покрывает интерфейсами логер, поэтому мы через замену текста меняем Timber на Napier.

Еще есть картинки, но кажется уже все давно перешли на Coil. Еще можно вспомнить префы, но на новых проектах сразу используют DataStore, который давно мультиплатформа, вроде ничего не забыл.

Итог: KMP никак не оправдывает избыточное использование интерфейсов, поскольку они здесь второстепенны. Успешный перенос проекта на KMP в первую очередь зависит от актуальности технологического стека. Даже если вы обложитесь интерфейсами по самые уши, но на проекте еще есть RxJava или View, то вы никуда быстро не передите.

❤25👍5🗿3

www.tgoop.com/dev_easy_notes/388

3.06K viewsMar 10 at 07:10

Закончим срач, про интерфейсы. Из всех аргументов "за", был только один связанный с практикой. Комент про то, как интерфейсы помогли разработчику перевести свой проект на KMP в краткие сроки.

Однако я считаю, что этот аргумент совершенно не относится к пользе интерфесов. Интерфейсы не дают существенных преимуществ при миграции на KMP, и объём работы остаётся примерно таким же. Поразгоняем эту мысль.

Рассмотрим типичное Android-приложение. Представим, что оно свежее и сразу разрабатывалось на Compose и корутинах. Уже только это решает значительную часть проблем при переходе на KMP. Cтандартный технологический стек для мобилки:

👉 Retrofit + OkHttp для сетевого взаимодействия
👉 Room для работы с БД (если оно вообще нужно)
👉 MVI для презентационного слоя (они уже все на базе корутин)
👉 Timber для логирования
👉 Dagger для внедрения зависимостей

Приложение мы пишем без лишних интерфейсов: Interactor, Presenter и даже Repository всегда просто классы. При условии что реализация только одна, если несколько, то разумеется делаем интерфейс.

Для переезда на KMP нам нужно два основных шага: перевести стек для сети и БД на мультиплатформу и вынести за интерфейсы платформенные компоненты (даты, UUID и подобное). Последнее заранее никто не выносит, если только не закладывали перенос заранее, поэтому в любом случае придется делать.

📞 Сеть. Retrofit изначально требует использования интерфейсов, поэтому эта часть уже готова. Мы просто то меняем зависимость на Ktorfit и заменяем OkHttp на Ktor. Возможно потребуется переписать интеракторы, но вы бы в любом случае их переписывали.

💽 БД. Если ее на проекте нет, то вы уже сделали 90% работы. Если же есть, то Room последней версии уже мультиплатформенная. Если же Room не нравится, то придется мигрировать на SQLDelight. Как бы вы не закрывались интерфейсами, у вас все равно будет дофига работы по мигрированию сущностей на другую либу. Все равно менять код Repository, поэтому профит интерфейса не ясен.

💉 DI. Если у вас был Dagger или Hilt или Anvil – вы в заднице. Теперь вам нужно или делать кастомный DI или переходить на Koin. Кстати если шарите, в комментариях подскажите, какие еще DI контейнеры мультиплатформенные?

📜 Логер. Никто никогда не покрывает интерфейсами логер, поэтому мы через замену текста меняем Timber на Napier.

Еще есть картинки, но кажется уже все давно перешли на Coil. Еще можно вспомнить префы, но на новых проектах сразу используют DataStore, который давно мультиплатформа, вроде ничего не забыл.

Итог: KMP никак не оправдывает избыточное использование интерфейсов, поскольку они здесь второстепенны. Успешный перенос проекта на KMP в первую очередь зависит от актуальности технологического стека. Даже если вы обложитесь интерфейсами по самые уши, но на проекте еще есть RxJava или View, то вы никуда быстро не передите.

BY Dev Easy Notes