Каковы преимущества сопутствующих объектов Scala по сравнению со статическими методами?

Scala не имеет статического ключевого слова, но вместо этого имеет аналогичную функциональность через сопутствующие объекты. За кулисами сопутствующие объекты компилируются в классы, которые имеют статические методы, поэтому все это синтаксический сахар. Каковы преимущества этого выбора дизайна? Недостатки? У других языков есть подобные конструкции?

Вот несколько причин, которые могут быть более или менее убедительными для вас, в зависимости от ваших собственных предпочтений:

1. Не стоит просто сбрасывать со счетов это за «синтаксический сахар». Хотя вы можете сказать, что что-то является просто синтаксическим сахаром, он, в конце концов, подслащивает вашу жизнь - как программист, так и любитель кофе или чая.

2. Синглтоны - каждый Scala objectпо своей сути является синглтоном. Учитывая, что в мире Java люди внедряют синглтоны разными способами, и чаще всего они совершают ошибку в своей реализации, вы не можете сделать такую ​​же простую ошибку, как в Scala. Письмо objectвместо того, чтобы classсделать это одиноким, и все готово.

3. Доступ к статическим методам: статические методы в Java могут быть доступны из объектов. Например, предположим, у вас есть класс Cсо статическим методом fи объект cтипа C. Затем вы должны позвонить C.f, но Java позволяет вам (хотя и с предупреждением) использовать c.f, что на самом деле не имеет смысла, когда вы выходите из фона Scala, потому что у объектов нет метода на fсамом деле.

4. Четкое разделение: в Java вы можете смешивать статические и нестатические атрибуты и методы в классе. Если вы работаете дисциплинированно, это не станет проблемой, однако, если вы (или кто-то еще в этом отношении) этого не сделаете, то вы получите чередование статических и нестатических частей, и это трудно определить с первого взгляда. что статично, а что нет. В Scala все, что находится внутри объекта-компаньона, не является частью объектов времени выполнения соответствующего класса, но доступно из статического контекста. И наоборот, если он написан внутри класса, он доступен для экземпляров этого класса, но не из статического контекста. Это становится особенно обременительным в Java, как только вы начинаете добавлять статические и нестатические блоки инициализатора в ваш класс. Это может оказаться очень трудным для понимания с точки зрения динамического порядка выполнения.

5. Меньше кода: вам не нужно добавлять слово static к каждому атрибуту или методу в object, таким образом, сохраняя код более кратким (на самом деле, на самом деле это не является заметным преимуществом).

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

Еще одним преимуществом является то, что objects может реализовывать интерфейсы / черты, в отличие от статических методов.

Сопутствующие объекты - это первое место, где ищутся следствия, после этого scala смотрит на Predef, а затем в явных выражениях «import» в этом конкретном исходном файле.

Я не достаточно разработчика Java, чтобы знать, предоставляют ли язык или библиотеки Java какой-либо сопоставимый механизм.