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

Question

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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