Size: a a a

Kotlin Community

2020 May 16

AI

Arkadii Ivanov in Kotlin Community
Представляйте данные дата классами, а взаимодействие с ними выносите в другие сущности.
источник

T

Tepex in Kotlin Community
Сержант Розеткинс
т.е. если я заранее знаю, что какая-то логика, даже минимальная, во взаимодействии с классом будет, то мне его уже точно дата классом не делать?
или отталкиваться от кол-ва функций, которые будут в классе, мол если одна, то тогда помечать класс как data class и эту функцию где-то в другом месте определять, а если условно больше трех, то уже обычным классом делать
Выделение логики (функций) во вне (с помощью функций-расширений) может показаться избыточным (есть издержки на статическую обертку под капотом). Но так правильней и чище с точки зрения архитектуры. Таким образом мы разделяем данные (по-хорошему, должны быть иммутабельные — data class с val полями и иммутабельными типами) и функционал. А еще лучше вообще модели генерить из метаданных, чтобы ни у кого не было возможности сделать их мутабельными (средствами языка сейчас такое не запретишь), но это отдельная тема.
источник

AN

Alexander Nozik in Kotlin Community
Сержант Розеткинс
решаю задачки из Kotlin Koans, тут везде в задачах дата классы, функционал которых реализован с помощью функций-расширений в других файлах.
забегая немного вперед хочу спросить, так действительно делается в продакшн коде на котлин или это просто здесь такое упрощение ради задачек?
т.е. что я имею ввиду
есть класс к примеру User у которого там метод void sayHello()

Java:
class User {
   String name;

   void sayHello() {
       System.out.print("hello!");
   }
}

Kotlin:
data class User(var name : String)

и в этом же файле (или в другом, например UserUtils) пишем:
fun User.sayHello() : Unit {
   print("Hello")
}

вот так всегда в котлин принято делать или делают обычно как в Java?
источник

AN

Alexander Nozik in Kotlin Community
Tepex
Выделение логики (функций) во вне (с помощью функций-расширений) может показаться избыточным (есть издержки на статическую обертку под капотом). Но так правильней и чище с точки зрения архитектуры. Таким образом мы разделяем данные (по-хорошему, должны быть иммутабельные — data class с val полями и иммутабельными типами) и функционал. А еще лучше вообще модели генерить из метаданных, чтобы ни у кого не было возможности сделать их мутабельными (средствами языка сейчас такое не запретишь), но это отдельная тема.
Какие ещё издержки?
источник

AN

Alexander Nozik in Kotlin Community
Вообще топ левел расширения дешевле обычных функций не сильно, но дешевле.
источник

АО

Алексей Овсянников... in Kotlin Community
Tepex
Выделение логики (функций) во вне (с помощью функций-расширений) может показаться избыточным (есть издержки на статическую обертку под капотом). Но так правильней и чище с точки зрения архитектуры. Таким образом мы разделяем данные (по-хорошему, должны быть иммутабельные — data class с val полями и иммутабельными типами) и функционал. А еще лучше вообще модели генерить из метаданных, чтобы ни у кого не было возможности сделать их мутабельными (средствами языка сейчас такое не запретишь), но это отдельная тема.
Издержки эти минимальны, как по мне. Главная проблема экстеншенов - для данных, генерируемых над иммутабельными данными, нет никакого кэша => несмотря на неизменяемость возвращаемых значений экстеншена, он постоянно будет вычисляться
источник

АО

Алексей Овсянников... in Kotlin Community
Поэтому иногда производительней будет положить поле в сам датакласс, но вычислять при создании, если известно, что использоваться это дело будет много где
источник

АО

Алексей Овсянников... in Kotlin Community
Причем с суммой всё просто с точки зрения вычислений, а вот если там что-то сложнее или происходит куча созданий объектов на каждый вызов (при одинаковом результате) - вот это уже может ударить по производительности
источник

AN

Alexander Nozik in Kotlin Community
Алексей Овсянников
Издержки эти минимальны, как по мне. Главная проблема экстеншенов - для данных, генерируемых над иммутабельными данными, нет никакого кэша => несмотря на неизменяемость возвращаемых значений экстеншена, он постоянно будет вычисляться
Ну сделать кэш в экстеншене ничуть не сложнее, чем в нормальном методе. Вообще, конечно, если у вас чего-то вычисляется и есть кэш и состояние, значит делать это дата классом уже не вполне корректно.
источник

AN

Alexander Nozik in Kotlin Community
Не надо впадать в крайонсти
источник

АО

Алексей Овсянников... in Kotlin Community
Ну я про экстеншены в целом
источник

AA

Anton Arhipov in Kotlin Community
Rodion Mostovoy
Друзья из JetBrains, скажите, а есть чат по райдеру? Бывает натыкаешься на баги, а issue заводить нет времени (тем более, вдруг уже есть?), вот было бы удобно сразу в чат скидывать информацию.
Чата не знаю, но это так себе стратегия - скидывать баги в чат. Это на деле столько же времени занимает - какая разница, куда ты текст пишешь, в чат или в трекер?

Ну если лень, пиши в Твиттер - от туда техподдержка может подхватить и в ютреке тикет оформить
источник

IO

Iaroslav Orlov in Kotlin Community
Alexander Nozik
Вообще топ левел расширения дешевле обычных функций не сильно, но дешевле.
если метод final и JIT ухитрился заменить вызовы на статистические, то цена одинакова
источник

AN

Alexander Nozik in Kotlin Community
Iaroslav Orlov
если метод final и JIT ухитрился заменить вызовы на статистические, то цена одинакова
На самом деле и виртуальный вызов почти бесплатный. Но мысль в том, что расширение всегда дешевле или равно.
источник

IO

Iaroslav Orlov in Kotlin Community
Alexander Nozik
На самом деле и виртуальный вызов почти бесплатный. Но мысль в том, что расширение всегда дешевле или равно.
ну, в теории одну нс утащит таблица виртуальных методов
источник

AN

Alexander Nozik in Kotlin Community
Iaroslav Orlov
ну, в теории одну нс утащит таблица виртуальных методов
одну нс тяжело заметить, и как вы верно заметили, обычно оно все-таки оптимизируется JIT-ом.
источник

IO

Iaroslav Orlov in Kotlin Community
Alexander Nozik
На самом деле и виртуальный вызов почти бесплатный. Но мысль в том, что расширение всегда дешевле или равно.
я думаю, что ради перфоманса лепить все экстешнами - очень странно. думаю, лучше их использовать, как и предначертано: если вызывать как метод хочется, а вставлять в апи класса противно 😐
источник

AN

Alexander Nozik in Kotlin Community
Iaroslav Orlov
я думаю, что ради перфоманса лепить все экстешнами - очень странно. думаю, лучше их использовать, как и предначертано: если вызывать как метод хочется, а вставлять в апи класса противно 😐
Безусловно согласен. Все в меру. Просто там наверху кто-то что-то сказал про дополнительные расходы на расширения, это было странно
источник

AM

Andrew Mikhaylov in Kotlin Community
Alexander Nozik
Ну сделать кэш в экстеншене ничуть не сложнее, чем в нормальном методе. Вообще, конечно, если у вас чего-то вычисляется и есть кэш и состояние, значит делать это дата классом уже не вполне корректно.
Ну как ничуть не сложнее, экстеншн разве что в своём синглтонном WeakHashMap-е каком-нибудь кешировать данные может, это чуть менее тривиально, чем в обычном методе к приватному полю класса обратиться...
источник

IO

Iaroslav Orlov in Kotlin Community
Andrew Mikhaylov
Ну как ничуть не сложнее, экстеншн разве что в своём синглтонном WeakHashMap-е каком-нибудь кешировать данные может, это чуть менее тривиально, чем в обычном методе к приватному полю класса обратиться...
да, это как-то очень криво звучит
источник