Комментарии 7
Современные библиотеки для работы с NoSQL обычно предоставляют готовые реализации Map<K, V>. Если их нет, то сделать реализацию Map с нужными методами, бросая UnsupportedOperationException из ненужных, дело пары минут. Этот контракт гораздо более применим по всей экосистеме JVM, чем новые обертки. Может у android'щиков такая нужда в них есть (зачем?), но точно не на бекенде.
P.S. Поставил плюсик за статью по программированию на сайте для гуманитариев))
Не совсем понял, при чем тут NoSql. Но окей. Допустим, вы используете одну либу для NoSql. У нее одна реализация для Map. Кто-то захотел другую либу для NoSql взять. Там уже другая обёртка. А вам нужно хранить одинаковый тип данных. С Крейтами вы просто оборачивание это в крейт и у вас код, где использовались Крэйты раньше, никак не меняется. Как и писал, это нужно для увеличения уровня абстракции.
Речь конечно не конкретно про NoSql. Тут именно подход для Key-Value хранения. В андроиднвх библиотеках, вроде как и у всех, абстракции разные. А Крэйты просто унифицируют этот доступ
Да, я понял что вы сделали абстракцию на уровне отдельных элементов. Но на мой взгляд это лишено смысла в силу существования Map<K, V> как абстракции для k-v хранилищ вообще. Поэтому привел пример что она уже и так решает поставленную проблему
Допустим, вы используете одну либу для NoSql. У нее одна реализация для Map. Кто-то захотел другую либу для NoSql взять. Там уже другая обёртка. А вам нужно хранить одинаковый тип данных.
И вот здесь как раз проблемы не возникнет, все методы принимают интерфейс Map<K, V> и оперируют им, ничего менять не придется. А "крейтами", представьте сколько оверхеда на отдельный элемент?
Может быть, просто не понимаю... Смогли бы вы привести пример кода до и после, где ваши крейты делают его лучше?
Нет, не все принимает на вход Map. Exposed - это вообще либа для SQL. Джавовские файлы тоже не принимают на вход Map. Jetpack DataStore не принимает на вход мама, к тому же там вообще флоу.
Крэйты для всех этих библиотек позволяют сделать единый унифицированный при, в котором не будет этих зависимостей. Крэйты убирают из кода полностью зависимость от конкретных библиотек.
На примере рассмотрим. Допустим, раньше хранили данные пользователя в SharedPreferences в жосне. Данные стали слишком большими, префоф стало недостаточно. Как хорошо что у нас были Крэйты. Мы теперь будем хранить данные пользователя локально в файле, а верхнеуровневый при останется такой же каким был. То же самое и с датастором и SQL
Ну и плюс не особо понятно, зачем тут вообще Map? У мапы совершенно другое применение. Вы видимо неверное вычитали смысл этой библиотеки. Спорить с тем, что я мог плохо это объяснить в статье не буду, так скорее всего и есть
Очень не хватает реализаций с сохранением в популярные хранилища как отдельные артефакты. Сейчас получается библиотеку берешь и надо дописать реализацию, что ей можно было пользоваться
KStorage — единый подход к key-value хранилищам на Kotlin Multiplatform