Идиоматический способ Scala иметь дело с именами полей базовых и производных классов?

Идиоматическим способом избежать дублирования поля было бы написать

abstract class Base { val x: String }

final class Derived(val x: String) extends Base {
   def toString = x
}

Однако в вашей версии похоже, что вам действительно нужно второе поле, поскольку у вас есть два разных значения. Как вы правильно заметили, присвоение этим полям одного и того же имени может привести к путанице.

Поскольку вам на самом деле не нужен аргумент конструктора вне конструктора, вы можете использовать этот подход (частный конструктор с сопутствующим модулем, который действует как фабрика):

abstract class Base { val x: String }

final class Derived private (val x: String) extends Base {
   def toString = x
}
object Derived {
   def apply(x: String) = new Derived("Base " + x)
}

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

В Java вы бы использовали метод доступа, такой как getX, чтобы добиться этого.

В Scala мы можем пойти еще дальше: vals, vars и defs занимают одно и то же пространство имен, поэтому val можно использовать для реализации абстрактного def (или для переопределения конкретного def, если вас это устраивает). Более формально это известно как «принцип единообразного доступа».

abstract class Base{ def x: String }

class Derived(val x: String) extends Base {
    override def toString = x
}

Если вам нужно, чтобы x можно было установить через ссылку на Base, вам также необходимо объявить "сеттер" (который затем можно реализовать с помощью var):

abstract class Base {
  def x: String
  def x_=(s: String): Unit
}

class Derived(var x: String) extends Base {
    override def toString = x
}

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

ОБНОВЛЕНИЕ

Преимущества этого подхода:

• x может быть полностью синтетическим значением, реализованным полностью с точки зрения других значений (например, площади круга, для которого вы уже знаете радиус)
• x может быть реализован на любой произвольной глубине в иерархии типов, и его не нужно явно передавать через каждый промежуточный конструктор (каждый раз с другим именем)
• Требуется только одно вспомогательное поле, поэтому память не тратится впустую.
• Поскольку теперь ему не нужен конструктор, Base можно реализовать как трейт; если ты так хочешь

Вы можете попробовать это:

abstract class Base( val x : String )

final class Derived( _x : String ) extends Base( _x ) {
  override val x  = "Base's " + _x
  override def toString = x
}

потом

println(new Derived("string").toString)

печатает именно то, что вы хотите

вы уже предоставили ответ, который работает

abstract class Base( val x : String )

final class Derived( _x : String ) extends Base( "Base's " + _x )
{
    override def toString = x
}

Если проблема в том, что _x не очень красивое имя, вам следует использовать осмысленное. В качестве альтернативы вы можете объявить свои классы следующим образом

abstract class Base( val _x : String )

final class Derived( x : String ) extends Base( "Base's " + x )
{
    override def toString = _x
}

И теперь у вас будет "хороший" синтаксис для инициализации Derived экземпляров.

Если бы scala позволяла

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

Мне это кажется очень низкоуровневой деталью, с которой вы не хотите иметь дело в коде. Если это можно сделать безопасно, компилятор должен сделать это за вас.

По предложению @jsuereth я создал улучшение, отмеченное галочкой для Scala, просто для записи, которое, я надеюсь, правильно суммирует содержание обсуждений здесь. Спасибо за ваш вклад! Билет можно найти здесь, содержание ниже: https://issues.scala-lang.org/browse/SI-4762

Непреднамеренное затенение полей базового класса в производных классах, желательно предупреждение

Проблема возникает всякий раз, когда (а) параметр класса в производном классе использует тот же символ, что и поле или функция в базовом классе, и (б) этот символ базового класса впоследствии используется в производном классе. Параметр производного класса заставляет компилятор автоматически генерировать поле с тем же именем, которое скрывает символ базового класса. Любая ссылка на этот символ в производном классе, предназначенная для ссылки на поле базового класса, затем непреднамеренно (а) вызывает дублирование определения поля и (б) неожиданно (но правильно) ссылается на автоматически сгенерированное поле в производном классе. .

Пример кода:

class Base( val x : String )
class Derived( x : String ) extends Base( x ) { override def toString = x }

Поскольку в классе «Base» есть «val» для генерации поля, а в производном классе нет, разработчик явно намеревается использовать «Derived» «x» только для передачи в Base, и поэтому ожидает ссылку в «toString». ', чтобы получить базовое значение. Вместо этого ссылка в «toString» заставляет компилятор автоматически генерировать поле «Derived.x», которое затеняет поле «Base.x», что приводит к ошибке. Компилятор ведет себя правильно, но в результате возникает ошибка программирования.

Сценарий использования (с полями var для наглядности рисков):

class Base( var x : Int ) { def increment() { x = x + 1 } }
class Derived( x : Int ) extends Base( x ) { override def toString = x.toString }

val derived = new Derived( 1 )
println( derived.toString )     // yields '1', as expected
derived.increment()
println( derived.toString )     // still '1', probably unexpected

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

Существует простой обходной путь для этой проблемы (используйте разные имена для параметра производного класса, например '_x', 'theX', 'initialX' и т. д.), но это приводит к нежелательным дополнительным символам.

Решение A (минимальное): выдавать предупреждение всякий раз, когда компилятор делает вывод о том, что для параметра класса требуется автоматически сгенерированное поле в производном классе, которое затеняет символ, уже определенный в базовом классе.

Решение B: обходной путь, по-прежнему необходимый для решения A, состоит в том, чтобы придумывать новое имя символа каждый раз, когда вы инициализируете поле базового класса. Этот сценарий возникает постоянно, и засорение пространства имен именами обходных полей, такими как «_x» и «theX», кажется нежелательным. Вместо этого было бы неплохо иметь способ подавить автоматическую генерацию полей, если разработчик решит, что в противном случае символы производного класса в конечном итоге скроют символ базового класса (например, после предупреждения решения A). Возможно, полезным дополнением к Scala был бы такой модификатор, как «noval» (или «passthrough», или «temp», или что-то еще — в дополнение к «val» и «var»), например:

class Base( var x : Int ) { def increment() { x = x + 1 } }
class Derived( noval x : Int ) extends Base( x ) { override def toString = x.toString }

val derived = new Derived( 1 )
println( derived.toString )     // yields '1', as expected
derived.increment()
println( derived.toString )     // still '2', as expected

Хорошо, прежде всего я хотел бы отметить, что ответ от @Yuriy Zubarev, вероятно, то, что вы действительно хотите получить. Во-вторых, я думаю, проблема может заключаться в вашем дизайне. Проверь это. Это часть вашего кода:

extends Base( "Base's " + _x )

Таким образом, некоторое значение x входит в ваш производный класс и модифицируется информацией (в данном случае "Base's " + ...). Ты видишь проблему? Почему ваш производный тип знает что-то, что должен был знать ваш базовый тип? Вот решение, которое я предлагаю.

abstract class Base {
    // this works especially well if you have a var
    // which is what you wanna have as you pointed out later.
    var x: String
    x = "Base's " + x
}

final class Derived(override var x: String ) extends Base{
   override def toString = x
}

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

@Gregor Scheidt, ваш код не работает, если я переведу toString() в Derived, как показано ниже:

object Test {
  abstract class Base ( val x: String)

  final class Derived(x: String) extends Base(x + " base") {
    override def toString() = x
  }

  def main(args: Array[String]): Unit = {
    val d  = new Derived( "hello")
    println( d) // hello
  }
}

В сообщении с официального сайта говорилось,

Такой параметр, как класс Foo(x : Int), превращается в поле, если на него ссылаются в одном или нескольких методах.

И ответ Мартина подтверждает его истинность:

Это все верно, но к этому следует относиться как к технике реализации. Поэтому спецификация об этом умалчивает.

поскольку нет способа предотвратить действие компилятора, мой вариант заключается в том, что более надежным способом ссылки на поле базового класса является использование другого имени, например, с использованием символа подчеркивания «_» в качестве префикса, как показано ниже:

object Test {
  abstract class Base ( val x: String)

  final class Derived(_x: String) extends Base(_x + " base") {
    override def toString() = x
  }

  def main(args: Array[String]): Unit = {
    val d  = new Derived( "hello")
    println( d) // hello
  }
}