Kotlin: статика, которой нет

a4ltihdnjfobccfvjc3sx3j3bm0.png
В этой статье пойдёт речь об использовании статики в Kotlin.
Начнём.
В Kotlin нет статики!

Об этом говорится в официальной документации.

И вроде бы на этом можно было бы и закончить статью. Но позвольте, как же так? Ведь если в Android Studio вставить код на Java в файл на Kotlin, то умный конвертер сделает магию, превратит всё в код на нужном языке и всё заработает! А как же полная совместимость с Java?

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

В чём проявляет себя статика в Java? Бывают:

  • статические поля класса
  • статические методы класса
  • статические вложенные классы

Проведём эксперимент (это первое, что приходит на ум).

Создадим простой Java-класс:

public class SimpleClassJava1 {

   public static String staticField = "Hello, static!";

   public static void setStaticValue (String value){
       staticField = value;
   }
}


Здесь всё легко: в классе создаём статическое поле и статический метод. Всё делаем публичным для экспериментов с доступом извне. Связываем поле и метод логически.

Теперь создадим пустой Kotlin-класс и попробуем скопировать в него всё содержимое класса SimpleClassJava1. На образовавшийся вопрос про конвертацию отвечаем «да» и смотрим что получилось:

class SimpleClassKotlin1 {

   var staticField = "Hello, static!"

   fun setStaticValue(value: String) {
       staticField = value
   }
}


Кажется, это не совсем то, что нам надо… Чтобы удостовериться в этом, преобразуем байт-код этого класса в Java-код и смотрим, что вышло:

public final class SimpleClassKotlin1 {
  @NotNull
  private String staticField = "Hello, static!";

  @NotNull
  public final String getStaticField() {
     return this.staticField;
  }

  public final void setStaticField(@NotNull String var1) {
     Intrinsics.checkParameterIsNotNull(var1, "");
     this.staticField = var1;
  }

  public final void setStaticValue(@NotNull String value) {
     Intrinsics.checkParameterIsNotNull(value, "value");
     this.staticField = value;
  }
}


Да. Всё именно так, как и показалось. Никакой статикой здесь и не пахнет. Конвертер просто обрубил в сигнатуре модификатор static, как будто его и не было. На всякий случай сразу cделаем вывод: не стоит слепо доверять конвертеру, иногда он может преподнести неприятные сюрпризы.

К слову сказать, примерно полгода назад конвертация того же Java-кода в Kotlin показала бы несколько иной результат. Так что ещё раз: осторожнее с автоматической конвертацией!

Экспериментируем дальше.

Идём в любой класс на Kotlin и пробуем вызвать в нём статические элементы Java-класса:

SimpleClassJava1.setStaticValue("hi!")
SimpleClassJava1.staticField = "hello!!!"


Вот как! Всё прекрасно вызывается, даже автозаполнение кода нам всё подсказывает! Довольно любопытно.

Теперь перейдём к более содержательной части. Действительно, создатели Kotlin решили уйти от статики в том виде, в котором мы привыкли её использовать. Зачем было сделано именно так и не иначе рассуждать не будем — споров и мнений по этому поводу в сети предостаточно. Мы же просто будем выяснять как с этим жить. Естественно, нас не просто так лишили статики. Kotlin даёт нам набор инструментов, которыми мы можем компенсировать утерянное. Они подходят для внутреннего использования. И обещанную полную совместимость с Java-кодом. Поехали!

Самое быстрое и простое, что можно осознать и начать использовать, — ту альтернативу, которую нам предлагают вместо статических методов, — функции уровня пакета. Что это такое? Это функция, не принадлежащая какому-либо классу. То есть эта некая логика, находящаяся в вакууме где-то в пространстве пакета. Мы можем описать её в любом файле внутри интересующего нас пакета. Например, назовём этот файл JustFun.kt и расположим его в пакете com.example.mytestapplication

package com.example.mytestapplication

fun testFun(){
    // some code
}

Преобразуем байт-код этого файла в Java и заглянем внутрь:

public final class JustFunKt {
  public static final void testFun() {
    // some code
  }
}


Видим, что в Java создаётся класс, имя которого учитывает название файла, в котором описана функция, а сама функция превращается в статический метод.

Теперь если мы хотим в Kotlin вызвать функцию testFun из класса (или такой же функции), находящемся в пакете package com.example.mytestapplication (то есть том же пакете, что и функция), то мы можем просто без дополнительных фокусов обратиться к ней. Если же мы вызываем её из другого пакета, то мы должны произвести импорт, привычный нам и обычно применимый к классам:

import com.example.pavka.mytestapplication.testFun


Если говорить про вызов функции testFun из Java-кода, то импорт функции нужно производить всегда, независимо от того из какого пакета мы её вызываем:

import static com.example.pavka.mytestapplication.ForFunKt.testFun;


В документации говорится, что в большинстве случаев вместо статических методов нам достаточно использовать функции уровня пакета. Однако, по моему личному мнению (которое не обязательно должно совпадать с мнением всех остальных), данный способ реализации статики подходит только для небольших проектов.
Получается, что эти функции не принадлежат явно какому-либо классу. Визуально их вызов выглядит как вызов метода класса (или его родителя), в котором мы находимся, что иногда может сбить с толку. Ну и главное — функция с таким названием может быть в пакете только одна. Даже если мы попробуем создать одноимённую функцию в другом файле, система выдаст нам ошибку. Если говорить про большие проекты, то у нас довольно часто бывают, например, разные фабрики, имеющие одноименные статические методы.

Посмотрим на другие альтернативы реализации статических методов и полей.

Вспомним, что такое статическое поле класса. Это поле класса, принадлежащее классу, в котором оно объявлено, но не принадлежащее конкретному инстансу класса, то есть создаётся в единственном экземпляре на весь класс.

Kotlin предлагает нам для этих целей использовать некую дополнительную сущность, которая так же существует в единственном экземпляре. Иначе говоря — синглтон.

Для объявления синглтонов в Kotlin имеется ключевое слово object.

object MySingltoneClass {
// some code
}

Инициализируются такие объекты лениво, то есть в момент первого обращения к ним.

Ок, в Java тоже есть синглтоны, причём здесь статика?

Для любого класса в Kotlin мы можем создать сопутствующий объект, или объект-компаньон. Некий синглтон, привязанный к конкретному классу. Это можно сделать, используя совместно 2 ключевых слова companion и object:

class SimpleClassKotlin1 {

companion object{

   var companionField = "Hello!"

   fun companionFun (vaue: String){
       // some code
   }
}
}

Здесь мы имеем класс SimpleClassKotlin1, внутри которого мы объявляем синглтон с помощью ключевого слова object и привязываем его к объекту, внутри которого он объявляется ключевым словом companion. Здесь можно обратить внимание на то, что в отличие от предыдущего объявления синглтона (MySingltoneClass) не указывается имя класса-синглтона. В случае, если объект объявлен компаньоном, допускается не указывать его имя. Тогда ему автоматически присвоится имя Companion. Если нужно, мы можем получить инстанс класса-компаньона таким образом:

val companionInstance = SimpleClassKotlin1.Companion


Однако, обращение к свойствам и методам класса-компаньона можно делать напрямую, через обращение класса, к которому он привязан:

SimpleClassKotlin1.companionField
SimpleClassKotlin1.companionFun("Hi!")


Это уже сильно похоже на вызов статических полей и классов, не так ли?

Если нужно, мы можем присвоить классу-компаньону имя, но на практике это делается очень редко. Из интересных особенностей сопутствующих классов можно отметить то, что он, как и любой обычный класс может реализовывать интерфейсы, что может помочь нам иногда внести в код чуть больше порядка:

interface FactoryInterface {
    fun factoryMethod(): T
}


class SimpleClassKotlin1 {

    companion object : FactoryInterface {
        override fun factoryMethod(): MyClass = MyClass()
    }
}

Класс-компаньон у класса может быть только один. Однако никто не запрещает нам объявлять внутри класса сколько угодно объектов-синглтонов, но в этом случае мы должны явно указать имя этого класса и, соответственно, указывать это имя при обращении к полям и методом этого класса.

Говоря ещё о классах, объявленных как object, можно сказать, что мы также можем в них же объявлять вложенные object, но не можем объявлять в них companion object.

Пора заглянуть «под капот». Возьмём наш простенький класс:

class SimpleClassKotlin1 {

   companion object{

       var companionField = "Hello!"
       fun companionFun (vaue: String){
       }
   }

   object OneMoreObject {

       var value = 1
       fun function(){
       }
   }

Теперь декомпилируем его байт-код в Java:

public final class SimpleClassKotlin1 {

  @NotNull
  private static String companionField = "Hello!";

  public static final SimpleClassKotlin1.Companion Companion = new SimpleClassKotlin1.Companion((DefaultConstructorMarker)null);

  public static final class OneMoreObject {
     private static int value;
     public static final SimpleClassKotlin1.OneMoreObject INSTANCE;

     public final int getValue() {
        return value;
     }

     public final void setValue(int var1) {
        value = var1;
     }

     public final void function() {
     }

     static {
        SimpleClassKotlin1.OneMoreObject var0 = new SimpleClassKotlin1.OneMoreObject();
        INSTANCE = var0;
        value = 1;
     }
  }

  public static final class Companion {
     @NotNull
     public final String getCompanionField() {
        return SimpleClassKotlin1.companionField;
     }

     public final void setCompanionField(@NotNull String var1) {
        Intrinsics.checkParameterIsNotNull(var1, "");
        SimpleClassKotlin1.companionField = var1;
     }

     public final void companionFun(@NotNull String vaue) {
        Intrinsics.checkParameterIsNotNull(vaue, "vaue");
     }

     private Companion() {
     }

     // $FF: synthetic method
     public Companion(DefaultConstructorMarker $constructor_marker) {
        this();
     }
  }
}


Смотрим, что же получилось.

Свойство объекта-компаньона представлено в виде статического поля нашего класса:

private static String companionField = "Hello!";

Похоже, что это именно то, чего мы хотели. Однако это поле приватное и доступ к нему осуществляется через геттер и сеттер нашего класса компаньона, который здесь представлен в виде public static final class, а его инстанс представлен в виде константы:

public static final SimpleClassKotlin1.Companion Companion = new SimpleClassKotlin1.Companion((DefaultConstructorMarker)null);

Функция companionFun не стала статическим методом нашего класса (наверное, и не должна была). Она так и осталась функцией синглтона, инициализированного в классе SimpleClassKotlin1. Однако, если вдуматься, то логически это примерно одно и то же.

С классом OneMoreObject ситуация очень похожая. Стоит отметить только то, что здесь, в отличии от компаньона поле класса value не переехало в класс SimpleClassKotlin1, а осталось в OneMoreObject, но также стало статическим и получило сгенерированные геттер и сеттер.

Попробуем осмыслить всё вышеописанное.
Если мы хотим реализовать статические поля или методы класса в Kotlin, то для этого следует воспользоваться companion object, объявленным внутри этого класса.
Вызов этих полей и функций из Kotlin будет выглядеть совершенно аналогично вызову статики в Java. А что будет, если мы попробуем вызвать эти поля и функции в Java?

Автозаполнение подсказывает нам, что доступны следующие вызовы:

SimpleClassKotlin1.Companion.companionFun("hello!");
SimpleClassKotlin1.Companion.setCompanionField("hello!");
SimpleClassKotlin1.Companion.getCompanionField();


То есть здесь мы никуда не денемся от прямого указания имени компаньона. Соответственно, здесь используется имя, которое присвоилось объекту-компаньону по умолчанию. Не очень удобно, так ведь?

Тем не менее, создатели Kotlin дали возможность сделать так, чтобы в Java это выглядело более привычно. И для этого есть несколько способов.

@JvmField
var companionField = "Hello!"


Если применить эту аннотацию к полю companionField нашего объекта-компаньона, то при преобразовании байт-кода в Java увидим, что статическое поле companionField SimpleClassKotlin1 уже не private, а public, а в статическом классе Companion пропали геттер и сеттер для companionField. Теперь мы можем обращаться из Java-кода к companionField привычным образом.

Второй способ — это указать для свойства объекта компаньона модификатор lateinit, свойства с поздней инициализацией. Не забываем, что это применимо только к var-свойствам, а его тип должен быть non-null и не должен быть примитивным. Ну и не забываем, про правила обращения с такими свойствами.

lateinit var lateinitField: String


И ещё один способ: мы можем объявить свойство объекта-компаньона константой, указав ему модификатор const. Несложно догадаться, что это должно быть val-свойство.

const val myConstant = "CONSTANT"


В каждом из этих случаев сгенерированный Java-код будет содержать привычное нам public static поле, в случае с const это поле будет ещё и final. Конечно, стоит понимать, что у каждого из 3х этих случаев есть своё логическое назначение, и только первый из них предназначен специально для удобства использования с Java, остальные получают эту «плюшку» как бы в нагрузку.

Отдельно следует отметить, что модификатор const можно использовать для свойств объектов, объектов-компаньонов и для свойств уровня пакета. В последнем случае мы получим то же, что и при использовании функций уровня пакета и с теми же ограничениями. Сгенерируется Java-код со статическим публичным полем в классе, имя которого учитывает имя файла, в котором мы описали константу. В пакете может быть только одна константа с указанным именем.

Если мы хотим, чтобы функция объекта-компаньона также преобразовалась в статический метод при генерации Java-кода, то для этого нам надо применить к этой функции аннотацию @JvmStatic.
Также допустимо применять аннотацию @JvmStatic к свойствам объектов-компаньонов (и просто объектов — синглтонов). В этом случае свойство не превратится в статическое поле, но будут сгенерированы статический геттер и сеттер к этому свойству. Для лучшего понимания посмотрим на вот этот Kotlin-класс:

class SimpleClassKotlin1 {

   companion object{

       @JvmStatic
       fun companionFun (vaue: String){
       }

       @JvmStatic
       var staticField = 1
   }
}

В данном случае из Java валидны следующие обращения:

int x;
SimpleClassKotlin1.companionFun("hello!");
x = SimpleClassKotlin1.getStaticField();
SimpleClassKotlin1.setStaticField(10);
SimpleClassKotlin1.Companion.companionFun("hello");
x = SimpleClassKotlin1.Companion.getStaticField();
SimpleClassKotlin1.Companion.setStaticField(10);

Из Kotlin валидны такие вызовы:

SimpleClassKotlin1.companionFun("hello!")
SimpleClassKotlin1.staticField
SimpleClassKotlin1.Companion.companionFun("hello!")
SimpleClassKotlin1.Companion.staticField

Понятно, что для Java следует использовать первые 3, а для Kotlin первые 2. Остальные вызовы всего лишь допустимы.

Теперь осталось прояснить последнее. Как быть со статическим вложенными классами? Тут всё просто — аналогом такого класса в Kotlin является обычный вложенный класс без модификаторов:

class SimpleClassKotlin1 {

   class LooksLikeNestedStatic {
   }
}

После преобразования байт-кода в Java видим:

public final class SimpleClassKotlin1 {

  public static final class LooksLikeNestedStatic {
  }
}

Действительно, это то, что нам нужно. Если мы не хотим, чтобы класс был final, то в Kotlin-коде указываем ему модификатор open. Вспомнил об этом на всякий случай.

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

И в завершении статьи вот ещё такая информация. Возможно, в будущем в Kotlin всё же появится модификатор static, устраняющий много вопросов и делающий жизнь разработчиков проще, а код короче. Такое предположение я сделал, обнаружив соответствующий текст в пункте 17 документа Kotlin feature descriptions.
Правда, документ этот датируется маем 2017 года, а на дворе уже конец 2018.

На этом у меня всё. Думаю, что тему разобрали довольно подробно. Вопросы пишите в комментарии.

© Habrahabr.ru