thừa kế lớp vỏ Scala

Question

Tôi có một ứng dụng dựa trên Squeryl. Tôi định nghĩa các mô hình của mình là các lớp chữ hoa, chủ yếu là vì tôi thấy thuận tiện để có các phương thức sao chép.

Tôi có hai mô hình có liên quan chặt chẽ. Các trường là giống nhau, nhiều thao tác là chung, và chúng được lưu trữ trong cùng một bảng DB. Nhưng có một số hành vi chỉ có ý nghĩa trong một trong hai trường hợp, hoặc có ý nghĩa trong cả hai trường hợp nhưng khác nhau.

Cho đến bây giờ tôi chỉ sử dụng một trường hợp đơn, với cờ phân biệt loại mô hình và tất cả các phương pháp khác nhau dựa trên loại mô hình bắt đầu bằng if. Điều này gây phiền toái và không khá an toàn.

Điều tôi muốn làm là yếu tố hành vi và trường phổ biến trong lớp trường hợp tổ tiên và có hai mô hình thực tế kế thừa từ nó. Nhưng, theo như tôi hiểu, kế thừa từ các trường hợp lớp học được cau mày khi ở Scala, và thậm chí bị cấm nếu lớp con là chính nó là một trường hợp lớp (không phải trường hợp của tôi).

What are the problems and pitfalls I should be aware in inheriting from a case class? Does it make sense in my case to do so?

Answer 1

cách ưa thích của tôi để tránh trường hợp lớp thừa kế mà không trùng lắp mã có phần rõ ràng: tạo ra một sinh hoạt chung (trừu tượng) lớp cơ sở:

abstract class Person { 
    def name: String 
    def age: Int 
    // address and other properties 
    // methods (ideally only accessors since it is a case class) 
} 

case class Employer(val name: String, val age: Int, val taxno: Int) 
    extends Person 

case class Employee(val name: String, val age: Int, val salary: Int) 
    extends Person 

Nếu bạn muốn trở thành hạt mịn hơn , nhóm các thuộc tính thành các đặc điểm riêng lẻ:

trait Identifiable { def name: String } 
trait Locatable { def address: String } 
// trait Ages { def age: Int } 

case class Employer(val name: String, val address: String, val taxno: Int) 
    extends Identifiable 
    with Locatable 

case class Employee(val name: String, val address: String, val salary: Int) 
    extends Identifiable 
    with Locatable 

Answer 2

lớp chữ thường là hoàn hảo cho các đối tượng giá trị, tức là các đối tượng không thay đổi bất kỳ thuộc tính nào và có thể được so sánh bằng các giá trị bằng.

Nhưng việc thực hiện bằng với sự hiện diện của thừa kế khá phức tạp. Hãy xem xét một hai lớp:

class Point(x : Int, y : Int) 

và

class ColoredPoint(x : Int, y : Int, c : Color) extends Point 

Vì vậy, theo định nghĩa các ColorPoint (1,4, đỏ) nên bằng với điểm (1,4) họ là những điểm tương tự sau tất cả. Vì vậy, ColorPoint (1,4, màu xanh) cũng phải bằng Điểm (1,4), phải không? Nhưng tất nhiên ColorPoint (1,4, màu đỏ) không nên bằng ColorPoint (1,4, màu xanh), bởi vì chúng có màu sắc khác nhau. Có bạn đi, một tài sản cơ bản của mối quan hệ bình đẳng bị phá vỡ.

cập nhật

Bạn có thể sử dụng thừa kế từ những đặc điểm giải quyết rất nhiều vấn đề như mô tả trong câu trả lời khác. Một lựa chọn linh hoạt hơn thường là sử dụng các lớp kiểu. Xem What are type classes in Scala useful for? hoặc http://www.youtube.com/watch?v=sVMES4RZF-8

Answer 3

Vì đây là một chủ đề thú vị đối với nhiều người, hãy để tôi làm sáng tỏ ở đây.

Bạn có thể đi với các phương pháp sau đây:

// You can mark it as 'sealed'. Explained later. 
sealed trait Person { 
    def name: String 
} 

case class Employee(
    override val name: String, 
    salary: Int 
) extends Person 

case class Tourist(
    override val name: String, 
    bored: Boolean 
) extends Person 

Vâng, bạn phải lặp lại trong các lĩnh vực. Nếu bạn không, nó sẽ không thể thực hiện bình đẳng chính xác among other problems.

Tuy nhiên, bạn không cần phải sao chép các phương pháp/chức năng.

Nếu việc sao chép một vài thuộc tính quan trọng đối với bạn, hãy sử dụng các lớp thông thường, nhưng hãy nhớ rằng chúng không phù hợp với FP.

Ngoài ra, bạn có thể sử dụng thành phần thay vì thừa kế:

case class Employee(
    person: Person, 
    salary: Int 
) 

// In code: 
val employee = ... 
println(employee.person.name) 

Thành phần là hợp lệ và một chiến lược âm thanh mà bạn nên xem xét là tốt.

Và trong trường hợp bạn tự hỏi những gì một đặc điểm niêm phong có nghĩa là - nó là cái gì đó có thể được mở rộng chỉ trong cùng một tập tin. Tức là, hai lớp vỏ trên phải nằm trong cùng một tệp. Điều này cho phép kiểm tra trình biên dịch đầy đủ:

val x = Employee(name = "Jack", salary = 50000) 

x match { 
    case Employee(name) => println(s"I'm $name!") 
} 

Cung cấp cho một lỗi:

warning: match is not exhaustive! 
missing combination   Tourist 

Đó là thực sự hữu ích. Bây giờ bạn sẽ không quên để đối phó với các loại khác của Person s (người). Đây là cơ bản những gì lớp học Option trong Scala hiện.

Nếu điều đó không quan trọng với bạn, thì bạn có thể làm cho nó không bị niêm phong và ném các lớp chữ hoa vào các tệp riêng của chúng. Và có lẽ đi với bố cục.

Answer 4

Trong những tình huống này tôi có xu hướng sử dụng thành phần thay vì thừa kế ví dụ:

sealed trait IVehicle // tagging trait 

case class Vehicle(color: String) extends IVehicle 

case class Car(vehicle: Vehicle, doors: Int) extends IVehicle 

val vehicle: IVehicle = ... 

vehicle match { 
    case Car(Vehicle(color), doors) => println(s"$color car with $doors doors") 
    case Vehicle(color) => println(s"$color vehicle") 
} 

Rõ ràng bạn có thể sử dụng một hệ thống phân cấp phức tạp hơn và các trận đấu nhưng hy vọng điều này sẽ cho bạn một ý tưởng. Điều quan trọng là tận dụng lợi thế của các bộ giải nén lồng nhau mà các trường hợp cung cấp