Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Предположим, что вы являетесь Android-разработчиком, который переходит на Kotlin и вы желаете зайти дальше<a>уровня data-классов</a>, планируя писать на Kotlin более сложные классы для фрагментов, активити, viewmodel-, interactor-, presenter-, repository- и прочих классов в зависимости от вашей архитектуры.

2 Допустим, в перспективе вы думаете полностью избавиться от Джавы в проекте. Все бы ничего, но сначала понадобится пройти довольно длинный путь устранения конфликтов между этими двумя языками.

3 Так как язык программирования Котлин изначально проектировался как JVM-язык, который полностью совместим с Java, вы без особых сложностей сможете наследоваться от существующих Джава-классов, а также обращаться к ним и использовать Java-аннотации к вашим методам и Kotlin-классам.

4 Но следует учесть, что есть несколько камней преткновения, которые образовались под влиянием, если можно так сказать, идеологических различий между 2-мя языками. О некоторых из них мы и поговорим.

5 <h2>GoingStatic</h2>

6 К примеру, в Kotlin отсутствует ключевое словоstatic, и с этим нужно просто смириться.

7 Но это не беда, ведь в нашем распоряжении естьcompanionobject. Речь идет о механизме объявления объекта внутри класса, причем этот механизм способен содержать внутри константы и методы, которые со стороны Джава будут синтаксически доступны, при этом в том же виде, как и статические поля либо Java-методы. Однако для того, чтобы при компиляции сгенерировались и статический метод класса, в котором, кстати, находится этот объект, да и метод этого объекта сам по себе, следует пометить его как@JvmStatic(по дефолту без этой аннотации метод companion-объекта является доступным посредством ссылки на Companion-инстанс).

8 Тему companionobjects, а также вопросы создания синглтонов и objectexpressions в Котлин подробно раскрывает вот<a>эта страница документации</a>.

9 Однако прежде, чем вы заключите ваши константы в companionobject-ы по всему проекту, учтите, что такие объекты не так уж дешевы, как это может показаться. Именно поэтому всем, кто планирует переходить на Котлин, рекомендуется ознакомиться с блоком статей "Kotlin’shiddencosts" (<a>part 1</a>,<a>part 2</a>,<a>part 3</a>). Эти статьи открывают обратную сторону синтаксического сахара с точки зрения байткода. Особое внимание следует обратить на советы по применению inline-функций для оптимизации производительности лямбда-выражений. Представляют интерес и рекомендации относительно того, как избежать избыточность автоупаковки/автораспаковки "под капотом".

10 <h2>Коллекции</h2>

11 Если мы говорим о коллекциях, то тут Kotlin полностью полагается на классы стандартной Java-библиотеки, расширяя их возможности посредством дополнительных функций для объявления (listOf(), mapOf(), etc), а также их модификаций и преобразований. Вообще, они относительно часто оказываются полезны и удобны в применении, поэтому с коллекциями в Kotlin в целом все неплохо и довольно прозрачно. По крайней мере,<a>почти…</a>

12 Также обратите внимание, что List, Map и Set являются алиасами для неизменяемых JDK-реализаций коллекций, а попытки поменять их содержимое обернутся UnsupportedOperationException, что, в принципе, логично.

13 <h2>Generics</h2>

14 Обобщения в Котлин тоже поддерживаются, однако есть важные различия в их реализации между 2-мя языками. Пренебрежение этими различиями способно привести вас к непредвиденным конфузным ситуациям. Вообще, эта разница подробно описана в документации и во многих тематических статьях. Вот некоторые материалы, неплохо раскрывающие ключевые для дженериков концепции ковариантности, инвариантности и контравариантности: • https://kotlinlang.org/docs/reference/generics.html; • https://proandroiddev.com/understanding-generics-and-variance-in-kotlin-714c14564c47; • https://typealias.com/guides/illustrated-guide-covariance-contravariance/.

15 <a>Источник</a>