Вот несколько причин, которые могут быть более или менее убедительными для вас, в зависимости от ваших собственных предпочтений:
Не стоит просто сбрасывать со счетов это за «синтаксический сахар». Хотя вы можете сказать, что что-то является просто синтаксическим сахаром, он, в конце концов, подслащивает вашу жизнь - как программист, так и любитель кофе или чая.
Синглтоны - каждый Scala objectпо своей сути является синглтоном. Учитывая, что в мире Java люди внедряют синглтоны разными способами, и чаще всего они совершают ошибку в своей реализации, вы не можете сделать такую же простую ошибку, как в Scala. Письмо objectвместо того, чтобы classсделать это одиноким, и все готово.
Доступ к статическим методам: статические методы в Java могут быть доступны из объектов. Например, предположим, у вас есть класс Cсо статическим методом fи объект cтипа C. Затем вы должны позвонить C.f, но Java позволяет вам (хотя и с предупреждением) использовать c.f, что на самом деле не имеет смысла, когда вы выходите из фона Scala, потому что у объектов нет метода на fсамом деле.
Четкое разделение: в Java вы можете смешивать статические и нестатические атрибуты и методы в классе. Если вы работаете дисциплинированно, это не станет проблемой, однако, если вы (или кто-то еще в этом отношении) этого не сделаете, то вы получите чередование статических и нестатических частей, и это трудно определить с первого взгляда. что статично, а что нет. В Scala все, что находится внутри объекта-компаньона, не является частью объектов времени выполнения соответствующего класса, но доступно из статического контекста. И наоборот, если он написан внутри класса, он доступен для экземпляров этого класса, но не из статического контекста. Это становится особенно обременительным в Java, как только вы начинаете добавлять статические и нестатические блоки инициализатора в ваш класс. Это может оказаться очень трудным для понимания с точки зрения динамического порядка выполнения.
Меньше кода: вам не нужно добавлять слово static к каждому атрибуту или методу в object, таким образом, сохраняя код более кратким (на самом деле, на самом деле это не является заметным преимуществом).
Недостатки найти гораздо сложнее. Можно утверждать, что статическая и нестатическая части должны принадлежать друг другу, но разделяются концепцией сопутствующих объектов в Scala. Например, может показаться странным иметь диаграмму классов, но в конечном итоге приходится создавать две вещи в коде и анализировать, какой атрибут идет куда.