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

Question

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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