Какова точка автогенерации геттеров/сеттеров для полей объектов в Scala?

Ответ 1

Для этого это позволяет обменивать общедоступный var/val с (несколькими) def (s) и поддерживать двоичную совместимость. Во-вторых, это позволяет переопределить var/val в производных классах.

Ответ 2

Во-первых, сохранение открытого поля позволяет клиенту читать и писать поле. Поскольку полезно иметь неизменяемые объекты, я бы рекомендовал сделать поле только для чтения (чего вы можете достичь в Scala, объявив его как "val", а не "var" ).

Теперь вернемся к вашему актуальному вопросу. Scala позволяет вам определять свои собственные сеттеры и геттеры, если вам нужно больше, чем тривиальные версии. Это полезно для сохранения инвариантов. Для сеттеров вы можете проверить значение, на которое установлено поле. Если вы оставите поле открытым, у вас нет шансов сделать это.

Это также полезно для полей, объявленных как "val". Предположим, у вас есть поле типа Array [X] для представления внутреннего состояния вашего класса. Теперь клиент может получить ссылку на этот массив и изменить его - снова у вас нет шансов обеспечить сохранение инварианта. Но поскольку вы можете определить свой собственный getter, вы можете вернуть копию фактического массива.

Тот же аргумент применяется, когда вы создаете поле ссылочного типа "final public" в Java - клиенты не могут reset ссылаться, но все же изменять объект, на который ссылаются ссылки.

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

Ответ 3

Вкратце: принцип равномерного доступа.

Вы можете использовать val для реализации абстрактного метода из суперкласса. Представьте следующее определение из некоторого воображаемого графического пакета:

abstract class circle {
  def bounds: Rectangle
  def centre: Point
  def radius: Double
}

Существует два возможных подкласса: один, где круг определен в терминах ограничивающего прямоугольника, и где он определяется в терминах центра и радиуса. Благодаря UAP, детали реализации могут быть полностью абстрагированы и легко изменены.

Также есть и третья возможность: ленивые деньги. Это было бы очень полезно, чтобы избежать повторного пересчета границ нашего круга снова и снова, но трудно представить, как ленивые валы могут быть реализованы без единого принципа доступа.