Pull to refresh

Comments 17

Функции-расширение - самое большое зло в Котлине, не могу придумать для них адекватного применения, но запутать очень легко.

Постоянно ими пользуюсь в пет проекте

  • при работе с БД через 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, емнип.

Короче, сравнивается тёплое с мягким. Причём с упором на разработку мобильных приложений.

Пункт 7 про исключения не понял, может кто пояснит?
В котлине нет Checked Exceptions. Тех, кого нужно обязательно кетчить. Типа, потому что бесполезно.

А откуда в котлине взялись примитивные тип, у которых:

Имена примитивных типов данных в Kotlin начинаются с заглавной буквы, например Boolean и Int

это реально блог компании которая обучает людей кодить за овер прайс?

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

Странно это, разве это не создаёт антирейтинг этой школе.

Сейчас бы в 2021 Java и Kotlin сравнивать...

Самое главное и приятное отличие отсутствие в Kotlin знака "; ")

Sign up to leave a comment.