Какова философия публикации переменных экземпляра по умолчанию в Scala?

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

6
scala

4 ответов

во-первых, вы должны знать, что когда вы пишете:

class Person( val name: String, val age: Int ) {
   ...
}

name и age не являются переменными экземпляра, но методы доступа (геттеры), которые являются общедоступными по умолчанию.

если вы напишете вместо этого:

class Person( name: String, age: Int ) {
   ...
}

name и age только переменные экземпляра, которые являются частными, как вы можете ожидать.

философия Скала предпочитают неизменяемые переменные экземпляра, то методы Public-аксессоров больше не проблема.

11

частный поощряет монолиты. Как только становится проще поместить несвязанные функции в класс только потому, что ему нужно прочитать некоторые переменные, которые являются частными, классы начинают расти.

Это просто плохой по умолчанию, и одна из больших причин для классов с более чем 1000 строк в Java.

Scala по умолчанию неизменяема, что удаляет массивный класс ошибок, которые люди часто используют private для ограничения (но не удаления, поскольку собственные методы класса все еще могут мутировать переменные) в Java.

5
  1. с неизменяемыми, которые предпочтительны во многих местах, public не так много проблем
  2. вы можете заменить общедоступный val геттерами и сеттерами без изменения кода клиента, поэтому вам не нужен дополнительный слой геттеров и сеттеров на всякий случай. (На самом деле вы получаете этот слой, но вы не замечаете его большую часть времени.)
  3. шаблон Java anti private field + public setters и getters не инкапсулирует много во всяком случае
3

(дополнительный вид, дополняющий другие ответы:)

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

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

в Scala методы и поля могут быть доступны с помощью эквивалентного синтаксиса - поэтому, если у вас есть простое свойство сейчас, нет потери в инкапсуляции, чтобы выставить его напрямую, так как вы можете выставить его как метод no-arg позже без ваших абонентов, которые должны знать что-либо об изменении.

3