具体的なクラスが持つ可能性のあるさまざまなプロパティに従って、ドメインオブジェクトを特性からアセンブルすることができます。オブジェクトが変更可能な場合、これはかなり簡単です。例えば:特に不変クラス階層の多態的な更新
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 }
、Iは、多形コンクリートタイプを知らなくても、任意の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
を更新しています。具体的なクラスがたくさんあり、さまざまなプロパティが混在している場合、定型コードの爆発を避ける最良の方法は何ですか?
右のM具体的なクラスのN更新メソッドの混乱は、私が避けたいものでした。そしてあなたが指摘しているように、それは動的言語ではかなり簡単です。このユースケースは明らかに非常に簡素化されていますが、不変の継承階層で更新を混在させると、問題が発生することがよくあります。 –
私はそれがScalaがうまく扱えないものだと主張するつもりはありませんが、私の経験上、頻繁に収穫されないシナリオです。もちろん、モデリングのこの時期にあなたが死んでいる場合を除きます。 –
おそらく、私はSapir-Whorfのことは何度ですか?言語がうまく処理できないシナリオは、頻繁に切り取られないシナリオになります。 –