Полиморфные обновления в неизменяемой иерархии классов
Я хотел бы иметь возможность собирать объекты домена из признаков, в зависимости от различных свойств, которые могут иметь конкретные классы. Когда мои объекты изменяемы, это довольно просто. Например:
trait HasHitPoints { var hitPoints: Int = 100 }
trait HasBearing { var bearing: Double = 0 }
class Ship extends HasHitPoints with HasBearing
class Base extends HasHitPoints
val entities = new Ship :: new Base :: Nil
entities.collect { case h: HasHitPoints => h.hitPoints += 10 }
В частности, я могу полиморфно читать или обновлять любой экземпляр HasHitPoints
, не зная конкретного типа.
Каков наилучший способ реализовать это с неизменяемыми объектами? Если я рад просто прочитать свойства, тогда я мог бы сделать что-то вроде:
trait HasHitPoints { val hitPoints: Int }
trait HasBearing { val bearing: Double }
case class Ship(hitPoints: Int, bearing: Double) extends HasHitPoints with HasBearing
case class Base(hitPoints: Int) extends HasHitPoints
val things = Ship(50, 0) :: Base(100) :: Nil
val totalHitPoints = things.collect { case h: HasHitPoints => h.hitPoints }.sum
Кроме того, я могу легко изменить конкретные классы, используя copy
, если я знаю точный тип. Например, жесткая часть обновляет произвольное HasHitPoints
. Если у меня много конкретных классов и множество разных свойств, которые я мог бы использовать для смешивания, какая лучшая схема, чтобы избежать взлома кода шаблона?
Ответы
Ответ 1
Возможно, вам повезло с добавлением, например, abstract def withHitPoints (points: Int) метод к вашим чертам, который возвращает копию объекта-контейнера с другим значением свойства. Это уменьшает использование до чего-то вроде:
val damagedActors = actors map { actor => actor.withHitPoints( actor.hitPoints - 10 ) }
Но в противном случае потребуется дополнительный метод для каждого свойства для конкретного класса, поэтому я не уверен, что он действительно решает вашу проблему. Это не кажется правильным для статического языка, такого как Scala (и я, вероятно, не буду настаивать на неизменности этого конкретного случая использования); непреложное решение здесь может быть лучшим кандидатом на динамический язык.
Ответ 2
Вы надеетесь избежать методов N обновления в конкретных классах M.
Как бы болезненно это ни казалось, это невозможно. Вам понадобится доступ к методу копирования или по крайней мере конструктору каждого конкретного класса. Ни один из них не может быть абстрагирован, как это также обсуждается в: абстракция метода класса экземпляра класса()
Таким образом, в конце концов вы всегда будете иметь код шаблона N x M.