Почему в Kotlin нет статического ключевого слова?

29

Kotlin известен прежде всего как замена Java, но он избавляется от известной конструкции Java: staticключевого слова. Вместо этого функциональность на уровне класса предлагается в основном сопутствующими объектами.

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

language-design

— user1446
источник

4

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

— Феникс

Есть ли у статических методов и тому подобного существенное преимущество перед сопутствующими объектами?

— Таннер Светт

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

— Score_Under

30

Scala также заменяет объявления уровня класса объектом 'Singleton'. Основным преимуществом этого является то, что все является объектом. В Java статические члены обрабатываются совсем иначе, чем члены объекта. Это означает, что вы не можете делать такие вещи, как реализация интерфейса или помещение «экземпляра» вашего класса в карту или передача его в качестве параметра методу, который принимает Object. Сопутствующие объекты учитывают эти вещи. Это преимущество.

— JimmyJames
источник

2

Неплохо подмечено. И я всегда думал, что странно, что есть синглтоны и статики, которые имеют очень похожее поведение, но только с сопутствующими объектами, это устраняет эту концептуальную странность.

— user1446

1

И именно поэтому в Java я предпочитаю определять методы для статически сконструированных объектов без сохранения состояния, а не определять статические методы.

— candied_orange

13

Ссылаясь на Kotlin справочные документы :

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

Мне кажется, очень похоже на то, что дизайнеры Kotlin видят в этом преимущество перед статическими членами Java.

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

— Док Браун
источник

6

Котлин - объектно-ориентированный язык. В объектно-ориентированном языке то, что не является объектом, является крайне вредным ограничением. Классы не являются объектами, но объекты являются объектами (дух!), Поэтому следует задать вопрос: почему язык не использует сопутствующие объекты?

Другим аспектом является простота: зачем иметь две вещи: объекты с членами экземпляра и классы со статическими членами, когда вы можете просто иметь объекты с членами экземпляра?

Альтернатива, которая используется во многих языках, производных от Smalltalk, состоит в том, чтобы самим создавать объекты. Например, в классах Smalltalk есть экземпляры параллельной иерархии метаклассов . В Ruby классы являются экземплярами Classкласса (и да, это означает, что Classэто экземпляр самого себя). В этом случае «методы класса» на самом деле являются обычными методами экземпляра метакласса класса. Я не знаю, почему этот дизайн не был выбран в Java (учитывая его близость к Smalltalk), но он может иметь какое-то отношение к упрощению системы типов (обратите внимание, что большинство языков с классами-как-объектами имеют тенденцию быть динамические языки).

— Йорг Миттаг
источник

1

«Другим аспектом является простота: зачем иметь две вещи: объекты с членами экземпляров и классы со статическими членами, когда вы можете просто иметь объекты с членами экземпляров?» Некоторые считают преимуществом иметь специальные конструкции для особых случаев или идиом.

— Джорджио

1

Я думаю , что это по крайней мере , можно утверждать , что Java делает (несколько) реализовать эту схему. Например, если у вас есть MyStaticClassнекоторые staticчлены, вы можете сослаться, MyStaticClass.classчтобы получить Classэкземпляр для этого класса. Затем вы можете использовать отражение, чтобы получить доступ к своим staticчленам. Все еще верно, что staticчлены фактически не привязаны ни к какому объекту (по крайней мере, концептуально; не уверены, что на самом деле делает Java под прикрытием). Но это означает, что по крайней мере некоторые из ограничений, поднятых в принятом ответе, не применяются строго .

— 17