Scala的模式匹配是否违反了开放/封闭原则？

如果我添加一个新的案例类,这是否意味着我需要搜索所有模式匹配代码并找出新类需要处理的位置？我最近一直在学习这门语言,当我读到一些支持和反对模式匹配的论据时,我一直很困惑它应该在哪里使用.请参阅以下内容:

Pro: Odersky1和 Odersky2

骗局: Beust

在每种情况下,评论都非常好.模式匹配是令人兴奋的东西还是我应该避免使用的东西？实际上,我认为答案是"这取决于你何时使用它",但它有哪些积极的用例和什么是负面用例？

杰夫,我认为你有正确的直觉:这取决于.

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

当您具有属于数据类型的相对固定的类集时,但具有基于模式匹配的功能的数据类型是很好的,但是许多可能在该数据类型上运行的函数.在这样的设置中,为数据类型添加新功能(在其所有类上只是模式匹配)相对容易,但添加属于数据类型的新类相对困难(您必须修改所有匹配的函数)在数据类型上,以确保它们正确支持新类).

面向对象方法的规范示例是GUI编程.GUI元素需要支持非常少的功能(在屏幕上绘制自己是最低限度的),但是新的GUI元素一直在添加(按钮,表格,图表,滑块等).模式匹配方法的规范示例是编译器.编程语言通常具有相对固定的语法,因此语法树的元素很少会发生变化(如果有的话),但是不断添加语法树上的新操作(更快的优化,更彻底的类型分析等).

幸运的是,Scala允许您将两种方法结合起来.案例类可以是模式匹配的,并支持虚拟方法调度.常规类支持虚方法分派,并且可以通过在相应的伴随对象中定义提取器来进行模式匹配.由程序员决定每种方法何时合适,但我认为两者都很有用.

虽然我尊重塞德里克,但他在这个问题上完全错了.当需要时,Scala的模式匹配可以从类更改中完全封装.虽然对案例类的更改确实需要更改任何相应的模式匹配实例,但这只是在以天真的方式使用这些类时.

Scala的模式匹配总是委托给类的伴随对象的解构函数.对于案例类,会自动生成此解构函数(以及随播对象中的工厂方法),但仍可以覆盖此自动生成的版本.在任何时候,您都可以断言对模式匹配过程的完全控制,使任何模式与类本身的潜在变化隔离开来.因此,模式匹配只是通过封装的安全过滤器访问类数据的另一种方式,就像任何其他方法一样.

因此,奥德斯基博士的观点将是值得信赖的人,特别是考虑到他在面向对象编程和设计领域所做的大量研究.

至于应该在哪里使用,这完全是根据口味.如果它使您的代码更简洁和可维护,请使用它!否则,不要.对于大多数面向对象的程序,模式匹配是不必要的.然而,一旦你开始集成更多的功能性成语(Option,List,等),我想你会发现,模式匹配会显著减少语法开销以及改善由类型系统所提供的安全性.通常,每当您想要在同时测试某些条件(例如从中提取值Some)的同时提取数据时,模式匹配可能会有用.