在某些情况下，您应该偏爱非案例类吗？
Martin Odersky在他的《 Scala中的函数式编程原理》（第4.6节-模式匹配）课程中为我们提供了一个很好的起点，当我们必须在类和案例类之间进行选择时，可以使用它。Scala示例示例的第7章包含相同的示例。
说，我们想为算术表达式编写一个解释器。为了使事情一开始很简单，我们将自己限制为数字和+运算。这样的表达式可以表示为一个类层次结构，以抽象基类Expr为根，以及两个子类Number和Sum。然后，表达式1 +（3 + 7）将表示为
新总和（新数字（1），新总和（新数字（3），新数字（7）））
abstract class Expr {
def eval: Int
}
class Number(n: Int) extends Expr {
def eval: Int = n
}
class Sum(e1: Expr, e2: Expr) extends Expr {
def eval: Int = e1.eval + e2.eval
}
此外，添加新的Prod类不需要对现有代码进行任何更改：
class Prod(e1: Expr, e2: Expr) extends Expr {
def eval: Int = e1.eval * e2.eval
}
相反，添加新方法需要修改所有现有类。
abstract class Expr {
def eval: Int
def print
}
class Number(n: Int) extends Expr {
def eval: Int = n
def print { Console.print(n) }
}
class Sum(e1: Expr, e2: Expr) extends Expr {
def eval: Int = e1.eval + e2.eval
def print {
Console.print("(")
print(e1)
Console.print("+")
print(e2)
Console.print(")")
}
}
案例类解决了相同的问题。
abstract class Expr {
def eval: Int = this match {
case Number(n) => n
case Sum(e1, e2) => e1.eval + e2.eval
}
}
case class Number(n: Int) extends Expr
case class Sum(e1: Expr, e2: Expr) extends Expr
添加新方法是本地更改。
abstract class Expr {
def eval: Int = this match {
case Number(n) => n
case Sum(e1, e2) => e1.eval + e2.eval
}
def print = this match {
case Number(n) => Console.print(n)
case Sum(e1,e2) => {
Console.print("(")
print(e1)
Console.print("+")
print(e2)
Console.print(")")
}
}
}
添加新的Prod类可能需要更改所有模式匹配。
abstract class Expr {
def eval: Int = this match {
case Number(n) => n
case Sum(e1, e2) => e1.eval + e2.eval
case Prod(e1,e2) => e1.eval * e2.eval
}
def print = this match {
case Number(n) => Console.print(n)
case Sum(e1,e2) => {
Console.print("(")
print(e1)
Console.print("+")
print(e2)
Console.print(")")
}
case Prod(e1,e2) => ...
}
}
来自视频讲座4.6模式匹配的抄录
这两种设计都非常好，有时之间的选择有时只是样式问题，但是仍然有一些重要的标准。
一个标准可能是，您是更经常创建新的表达式子类，还是更经常创建新方法？因此，这是一个考量未来系统可扩展性和系统可能通过扩展的标准。
如果您要做的主要是创建新的子类，那么面向对象的分解解决方案将占据上风。原因是使用eval方法创建新的子类非常容易且非常本地化，与功能解决方案一样，您必须返回并更改eval方法中的代码并添加一个新案例对它。
另一方面，如果您要做的是创建许多新方法，但是类层次结构本身将保持相对稳定，则模式匹配实际上是有利的。同样，因为模式匹配解决方案中的每个新方法都只是局部更改，无论您将其放在基类中，甚至可能放在类层次结构之外。每个子类都是一个新方法，例如在面向对象分解中使用show，它需要一个新的增量。所以会有更多的部分，您必须触摸。
因此，这种在二维上具有可扩展性的问题（您可能想在层次结构中添加新的类，或者您想添加新的方法，或者两者都被称为表达式问题）。
请记住：我们必须以此为起点，而不是唯一的标准。
