從技術角度看，五月混合特徵可以擴展案例類別嗎？

Question

我在SO上反覆閱讀，因爲案例類默認實現了一個等式方法，因此導致了相等問題，因此不應該擴展案例類。但是，如果一個特質擴展了一個case類，那麼這是否也有問題？

case class MyCaseClass(string: String) 
trait MyTrait extends MyCaseClass 
val myCT = new MyCaseClass("hi") with MyTrait 

我想這歸結爲問題，MyTrait是否僅強制爲可混合只進MyCaseClass的實例化或是否MyTrait爲繼承MyTrait的類成員（字段值和方法），從而覆蓋它們。在第一種情況下，從MyCaseClass繼承是可以的，在後一種情況下它不會好。但是哪一個呢？

研究，我提出我的實驗

trait MyTrait extends MyCaseClass { 
    def equals(m: MyCaseClass): Boolean = false 
    def equals(m: MyCaseClass with MyTrait): Boolean = false 
} 
val myC = new MyCaseClass("hi") 
myCT.equals(myC) // res0: Boolean = true 

讓我相信，MyCaseClass的平等使用，MyTrait的不是一個。這表明，一個特質可以擴展一個case類是可以的（儘管類不能擴展case類）。

但是，我不確定我的實驗是否合法。你能否就這個問題提出一些看法？

Answer 1

基本上，性狀可以擴展爲any class，所以最好將它們用於常規類（OOP風格）。

反正你平等的合同仍然是斷開的，無論你的絕招​​（注意，標準Java的equals定義上Any，所使用的默認情況下，讓我們在HashMap甚至==說）：

scala> trait MyTrait extends MyCaseClass { 
    | override def equals(m: Any): Boolean = false 
    | } 
defined trait MyTrait 

scala> val myCT = new MyCaseClass("hi") with MyTrait 
myCT: MyCaseClass with MyTrait = MyCaseClass(hi) 

scala> val myC = new MyCaseClass("hi") 
myC: MyCaseClass = MyCaseClass(hi) 

scala> myC.equals(myCT) 
res4: Boolean = true 

scala> myCT.equals(myC) 
res5: Boolean = false 

此外， Hashcode/equals是不是唯一的原因...

與其他類擴展case class是不自然的，因爲case class代表ADT所以它僅機型數據 - 不行爲。

這就是爲什麼你不應該添加任何方法（在OOD條款case class es是專爲貧血的方法）。因此，排除方法後 - 一個特點，只能用類混合變成廢話的使用特點與case類的點是模擬析取（這樣特質的接口在這裏 - 不混合插件）：

//your data model (Haskell-like): 
data Color = Red | Blue 

//Scala 
trait Color 
case object Red extends Color 
case object Blue extends Color 

如果Color只能用Blue混合 - 這是一樣

data Color = Blue 

即使你需要更復雜的數據，像

//your data model (Haskell-like): 
data Color = BlueLike | RedLike 
data BlueLike = Blue | LightBlue 
data RedLike = Red | Pink 

//Scala 
trait Color extends Red 
trait BlueLike extends Color 
trait RedLike extends Color 
case class Red(name: String) extends RedLike //is OK 
case class Blue(name: String) extends BlueLike //won't compile!! 

結合Color只有Red似乎不是一個好方法（一般），因爲你將無法case object Blue extends BlueLike

P.S.案例類不打算用於OOP風格（混入是OOP的一部分） - 它們與類型類/模式匹配更好地交互。所以我建議將你的複雜類似方法的邏輯從case class中移走。一種方法可以是：

trait MyCaseClassLogic1 { 
    def applyLogic(cc: MyCaseClass, param: String) = {} 
} 

trait MyCaseClassLogic2 extends MyCaseClassLogic { 
    def applyLogic2(cc: MyCaseClass, param: String) = {} 
} 

object MyCaseClassLogic extends MyCaseClassLogic1 with MyCaseClassLogic2 

你可以使用自助型或trait extends在這裏，但你可以很容易地發現，這是多餘的，因爲applyLogic勢必MyCaseClass只:)

另一種方法是implicit class（或者你可以嘗試更類似類型的先進的東西）

implicit class MyCaseClassLogic(o: MyCaseClass) { 
    def applyLogic = {} 
} 

PS2貧血與豐富。因爲它適用於不可變（無狀態）數據，所以它不是精確的貧血模型。如果您閱讀the article，Martin Fowler的方法是OOP/OOD，默認情況下是有狀態的 - 這就是他在文章的大部分部分中所暗示的，暗示服務層和業務層應該具有不同的狀態。在FP中（至少在我的實踐中），我們仍然將領域邏輯與服務邏輯分開，但是我們也將操作與數據分開（在每一層中），這是另一回事。

Answer 2

擴展大小寫類是一種不好的做法（通常），因爲它具有實際意義 - 「數據容器」（POJO/ADT）。例如，Kotlin不允許這樣做。

另外，如果你真的想一些特徵來擴展類的情況下，你最好使用requires依賴（以避免情況下類繼承的陷阱）：

scala> case class A() 
defined class A 

scala> trait B { self: A => } 
defined trait B 

scala> new B{} 
<console>:15: error: illegal inheritance; 
self-type B does not conform to B's selftype B with A 
    new B{}