В чем преимущество объектов comapion вместо статических методов и полей?

Я спрашиваю себя, почему Kotlin использует сопутствующие объекты вместо статических методов и полей? Это сокращение шаблона? Я думаю, что проще написать объект-компаньон со всеми свойствами и функциями внутри фигурных скобок вместо того, чтобы каждый раз писать статические. Вот пример.

class Hero {
    companion object {
        private var numberOfHeroes = 0

        fun addNewHero() {
            numberOfHeroes++
        }

        fun deleteHero() {
            numberOfHeroes--
        }

        fun getAllHeroes(): Int {
            return numberOfHeroes
        }
    }

    init {
        addNewHero()
    }
}

fun main() {

    val h1 = Hero()
    val h2 = Hero()

    print("Number of heros: ${Hero.getAllHeroes()}") // result is 2
}

Но разве это единственное преимущество? Я знаю, что краткость очень важна для Kotlin, но я думаю, что будет немного больше.


java kotlin static companion-object
person Torben G    schedule 10.03.2020    source источник
comment
Это помогает указать на логическое разделение между членами класса и членами компаньона. Статические члены класса на самом деле не являются частью класса в объектно-ориентированном смысле, они просто что-то, что живет в том же пространстве имен. Вынуждая их объявлять по отдельности, различие сохраняется, а не просто смешивать все вместе.   -  person Andy Turner    schedule 10.03.2020
comment
companion object может получать функции расширения, а также реализовывать интерфейсы.   -  person EpicPandaForce    schedule 10.03.2020
comment
Итак, вы имеете в виду, что в java не совсем очевидно, что статические поля и методы на самом деле не являются частью объектов? Но так ли дело с котлином? Я думаю, вам нужно записать это в объявлении класса. Итак, единственное разделение существует через оболочку сопутствующего объекта?   -  person Torben G    schedule 10.03.2020

Ответы (1)


arrow_upward
1
arrow_downward

Нет никакой пользы (или недостатка, если на то пошло) в том, чтобы делать то или другое. Это просто языковая конструкция. И, честно говоря, вы должны спросить, в чем преимущество сопутствующих объектов и функций расширения по сравнению со статическими методами.

Java и большинство других объектно-ориентированных языков решили использовать статические поля для случаев, когда должен существовать только один экземпляр поля, и статические методы для случаев, когда а) экземпляр класса не имеет значения или не важен, или б) это действительно так, но разработчик, пишущий статический метод, не контролирует класс, то есть пользователь хочет расширить функциональность существующего класса, автор которого он / она не является исходным автором (предоставьте служебную функцию, чтобы говорить).

Примером последнего может быть служебный метод для класса String, который проверяет, является ли рассматриваемая строка пустой (состоит только из пробелов или пуста). Конечные пользователи не могут изменять класс String напрямую, поэтому возникает необходимость написать служебный класс со статическим методом (ами). Эта задача прекрасно решается в Kotlin с помощью функций расширения и / или свойств.

person ysakhno    schedule 10.03.2020
comment
Спасибо вам тоже за вашу помощь. Но я думаю, что обернуть статические методы в сопутствующий объект является преимуществом из-за возможности вызывать на нем функции расширения. Но да, это преимущество обоих вместе, объектов-компаньонов и функций расширения. Но, на мой взгляд, реализация интерфейсов - тоже преимущество. Таким образом, это не полностью отличается от статических полей в java, но есть небольшая разница. - person Torben G; 11.03.2020