Oop Scala'；s模式匹配是否违反开放/封闭原则？

如果我添加一个新的case类，这是否意味着我需要搜索所有的模式匹配代码，并找出新类需要处理的地方？我最近一直在学习这种语言，当我读到一些支持和反对模式匹配的论据时，我对它应该在哪里使用感到困惑。见下文：

赞成者： 及

反对：

---

在每种情况下，评论都非常好。那么，模式匹配是值得兴奋的事情还是我应该避免使用的事情呢？事实上，我想答案是“这取决于你什么时候使用它”，但它有哪些积极的用例，哪些消极的用例呢？

虽然我尊重塞德里克，但他在这个问题上完全错了。Scala的模式匹配可以在需要时从类更改中完全封装。虽然对case类的更改确实需要更改任何相应的模式匹配实例，但这只是在以一种幼稚的方式使用此类类时才会发生

Scala的模式匹配总是委托给类的伴生对象的解构器。对于case类，这个解构器是自动生成的（与伴随对象中的工厂方法一起），尽管它仍然可以覆盖这个自动生成的版本。在任何时候，您都可以断言对模式匹配过程的完全控制，将任何模式与类本身的潜在更改隔离开来。因此，模式匹配只是通过封装的安全过滤器访问类数据的另一种方式，就像任何其他方法一样

因此，Odersky博士的观点值得信赖，特别是考虑到他在面向对象编程和设计领域所做的大量研究

---

至于在哪里使用，那完全取决于口味。如果它使您的代码更简洁、更易于维护，请使用它！否则，不要。对于大多数面向对象的程序，模式匹配是不必要的。但是，一旦您开始集成更多的功能性习惯用法（

选项

，

列表

，等等），我想您会发现模式匹配将显著减少语法开销，并提高类型系统提供的安全性。一般来说，在同时测试某些条件（例如，从

某些

中提取值）时，模式匹配可能会有用。

如果您正在进行函数式编程，则模式匹配肯定很好。在OO的情况下，有些情况下它是好的。在Cedric的示例中，这取决于您在概念上如何查看

print（）

方法。它是每个

术语
对象的行为吗？还是它之外的东西？我会说它是外部的，而且进行模式匹配是有意义的。另一方面，如果您有一个包含各种子类的
Employee
类，那么在基类中对其属性（比如名称）进行模式匹配是一个糟糕的设计选择

此外，模式匹配还提供了一种优雅的方式来解包类成员。
Jeff，我认为你的直觉是正确的：这取决于情况

当您有一组相对固定的方法需要实现，但有许多潜在的子类可能从层次结构的根继承并实现这些方法时，使用虚拟方法分派的面向对象类层次结构是很好的。在这样的设置中，添加新的子类相对容易（只需实现所有方法），但添加新方法相对困难（必须修改所有子类以确保它们正确实现新方法）

当您拥有属于某个数据类型的一组相对固定的类，但有许多潜在函数在该数据类型上运行时，具有基于模式匹配的功能的数据类型是很好的。在这样的设置中，为数据类型添加新功能相对容易（仅在其所有类上进行模式匹配），但添加作为数据类型一部分的新类相对困难（必须修改与数据类型匹配的所有函数，以确保它们正确支持新类）

面向对象方法的典型例子是GUI编程。GUI元素只需要支持很少的功能（在屏幕上绘制自己是最低要求），但始终会添加新的GUI元素（按钮、表格、图表、滑块等）。模式匹配方法的典型示例是编译器。编程语言通常有一个相对固定的语法，因此语法树的元素很少改变（如果有的话），但是语法树上的新操作不断增加（更快的优化，更彻底的类型分析，等等）

幸运的是，Scala允许您结合这两种方法。案例类既可以是模式匹配的，也可以支持虚拟方法分派。常规类支持虚拟方法分派，并且可以通过在相应的伴随对象中定义提取器进行模式匹配。由程序员决定每种方法何时合适，但我认为这两种方法都很有用。
Beust链接断开，显然会改变URL方案。我试着看看我是否能弄清楚哪个帖子是有意的，但我不确定。请提供一个正确的链接，或者提供更多信息（文章的标题是什么？）。相关：