Комментарии 18
Функции-расширение - самое большое зло в Котлине, не могу придумать для них адекватного применения, но запутать очень легко.
Постоянно ими пользуюсь в пет проекте
при работе с БД через Exposed - есть своя библиотека со схемой и дата классами. Если использующий библиотеку проект что-то должен сделать специфическое с данными дата класса, я это оформляю через расширение
В ту же библиотеку, с БД и Exposed я постоянно добавляю что-то своё, чего в Exposed нет, но что достаточно типовое. Например, получение следующего числа последовательности, часто используемые функции и т.п.
Иногда в сторонней библиотеке надо что-нибудь доложить в private поле, я быстренько делаю расширение и через рефлексию докидываю.
Очень удобный механизм. Жаль на работе не разрешают Котлин использовать (мотивируя это тем, что поддерживать некому будет)
но это все очень неочивидно и как это поддерживать. Ведь зайдя в класс ты ожидаешь там увидеть всю реализацию, а тут приходится собирать ее по разным местам. Рефлексия так вообще.. Бррр, это может работать на пет проекте, но в крупном проде - будет кошмар. Гораздо лучше форкануть либу или , накрайняк, самому написать, чем рефлексией или расширениями делать новый функционал
Ну да, случается. Я иногда находил несколько экземпляров одного и того же расширения у себя в разных местах. С другой стороны, а если бы я это добавлял в data class? Получился бы страшный класс, да ещё и библиотеку пришлось бы релизить чаще.
Думаю, это вопрос привычки. Нашим джавистам и ломбоковский val не нравится, они это аргументируют почти как вы (заходя в класс, я ожидаю перед объявлением переменной увидеть её тип).
Для мапинга очень удобно. И зачем тебе внутри класса знать что кто-то твою сущность в свой объект переделывает? И не надо плодить классы маперы. Для списков в самом котлине море полезных экстеншенов, для стринги. Например метод orEmpty на нулабельных списке или строке вернёт пустой список или строку, а не налл
Конечно когда ты не используешь язык профессионально в командах то много не понимаешь, но экстеншены уже во многих языках есть и используется для многих вещей.
Дизайн библиотек. Там как раз очень удобно отделять интерфейсы и их реализации от всяких побочных методов, нужных только для удобства API.
Например, они активно используются в jetpack compose в Modifier. В зависимости от текущего скоупа у Modifier доступны те или иные методы расширения. Если у нас BoxScope, то нам доступны дополнительно Modifier.aling() и Modifier.matchParentSize(), где они имеют смысл. И не путаются под ногами в других местах.
Также возможность элегантно расширить контрол, в котором авторы не додумали сделать нужное. Без этого в jetpack compose пришлось бы изворачиваться как в swiftUI (хотя там тоже неплохо, но не так гибко).
Ну а Flow<> своими методами как иначе расширять?!
Конечно гибкость вида "подключили библиотеку и у нас появились дополнительные методы" обладает обратной стороной "скопировал код с so и все горит красным, не пойму что импортировать и где искать".
Обожаю котлин, но 70% статьи не сравнение котлина и джавы, а описание котлина
Код, написанный на Kotlin, намного компактнее по сравнению с Java — на 30–40 %.
Таким образом, в теории размер приложений может уменьшиться на треть.
ЛПП. Уменьшиться может размер исходных кодов, но никак не приложения. Байт-код-то будет +/- один и тот же.
Java позволяет разработчикам присваивать значение
nullлюбой переменной.
Опять неправда. Примитиву нельзя присвоить null.
Изменяемым (mutable) и неизменяемым (immutable) типами в Kotlin являются
varиval
Это не типы, а способы объявления переменных и полей.
В числовых литералах разрешается использовать символы подчеркивания.
Это вообще фича java с версии 1.5, емнип.
Короче, сравнивается тёплое с мягким. Причём с упором на разработку мобильных приложений.
А откуда в котлине взялись примитивные тип, у которых:
Имена примитивных типов данных в Kotlin начинаются с заглавной буквы, например
BooleanиInt
это реально блог компании которая обучает людей кодить за овер прайс?
Сейчас бы в 2021 Java и Kotlin сравнивать...
Самое главное и приятное отличие отсутствие в Kotlin знака "; ")
Сравниваем Java и Kotlin