Companion object в Kotlin: замена Java static и производительность

Почему в Kotlin нет static, но есть companion object? Разбираемся с производительностью и логикой

Если вы переходите с Java на Kotlin, то один из первых вопросов, который возникнет у вас на StackOverflow (и он действительно собрал тысячи просмотров), звучит так: «Почему мы используем companion object вместо Java static? И не тормозит ли это приложение?»

Давайте честно: когда я впервые увидел конструкцию companion object, мне показалось, что Kotlin-команда просто решила усложнить жизнь. Зачем писать больше кода, если можно было просто скопировать static из Java? Но, покопавшись глубже, я понял: это не прихоть, а продуманное архитектурное решение, которое делает код чище, безопаснее и… да, иногда даже быстрее.

В этой статье мы не просто переведём ответ с SO. Мы разберём, как работает companion object под капотом, сравним производительность с Java static и покажем, когда его использовать, а когда лучше выбрать другой путь.

Что такое companion object простыми словами?

В Java статические поля и методы принадлежат классу, а не экземпляру. В Kotlin решили уйти от ключевого слова static, потому что оно нарушает принципы ООП (статику нельзя переопределить, она не является частью объекта). Вместо этого Kotlin предлагает объекты-компаньоны.

Представьте, что у вас есть класс User. Вы хотите хранить константу MAX_AGE и фабричный метод createGuest(). В Java вы бы написали:

public class User {
    public static final int MAX_AGE = 120;
    public static User createGuest() {
        return new User("guest", "1234");
    }
}

В Kotlin это выглядит так:

class User(private val name: String, private val password: String) {
    companion object {
        const val MAX_AGE = 120
        fun createGuest() = User("guest", "1234")
    }
}

Обратите внимание: companion object — это не просто «static-блок». Это полноценный объект, который живёт внутри вашего класса. У него могут быть интерфейсы, расширения и даже своё имя (если вы его зададите).

Как companion object работает под капотом? (Глазами JVM)

Чтобы понять производительность, давайте заглянем в байткод. Когда вы пишете companion object, Kotlin-компилятор делает следующее:

• Создаёт внутренний статический класс с именем Companion (или вашим кастомным именем).
• Помещает все поля и методы из companion object в этот класс.
• Если вы используете аннотацию @JvmStatic, компилятор дополнительно генерирует статические методы-обёртки в самом классе.

Пример с аннотацией @JvmStatic:

class User {
    companion object {
        @JvmStatic
        fun createGuest() = User()
    }
}

Теперь из Java вы можете вызвать User.createGuest() как обычный статический метод. Без этой аннотации пришлось бы писать User.Companion.createGuest().

Вывод для производительности: если вы работаете только с Kotlin, дополнительных накладных расходов нет. Если вызываете из Java — один лишний уровень косвенности (через объект Companion). Но JIT-компилятор JVM отлично in-line'ит такие вызовы, поэтому разница в скорости стремится к нулю.

Производительность: companion object vs Java static

Давайте развеем главный миф: companion object НЕ тормозит. Я провёл несколько микро-бенчмарков (на Kotlin 1.9, JVM 17), и вот что получилось:

Разница в пределах погрешности измерения. На практике вы никогда не заметите эти микросекунды, если, конечно, не пишете сверхвысоконагруженный финансовый движок на Kotlin (но там и static не спасёт — нужны нативные оптимизации).

Когда companion object — это плохо? (Честно о недостатках)

Несмотря на хорошую производительность, есть пара моментов, где companion object может быть не лучшим выбором:

1. Тестирование

Статические методы в Java и companion object в Kotlin одинаково плохо поддаются мокированию (если вы не используете Mockito с PowerMock). Если вам нужно замокать фабричный метод, лучше вынести его в отдельный интерфейс и использовать DI (Dagger, Koin, Kodein).

2. Размер APK на Android

Каждый companion object генерирует дополнительный класс в байткоде. На Android это может добавить пару килобайт к размеру APK. Для больших проектов с сотнями companion object это может стать заметно — но опять же, речь о единицах процентов от общего размера.

3. Наследование и интерфейсы

В отличие от Java static, companion object может реализовывать интерфейсы. Это круто, но иногда сбивает с толку: вы можете написать MyClass.MyInterface.method(), что выглядит неочевидно.

Лучшие практики: как использовать companion object с умом

Чтобы ваш код был не только красивым, но и быстрым, придерживайтесь нескольких правил:

• Используйте const val для констант примитивных типов и String. Это гарантирует, что значение будет встроено прямо в байткод, без обращения к объекту Companion.
• Добавляйте @JvmStatic только если ваш код вызывается из Java. Для чисто Kotlin-