Scala的模式匹配是否违反了开放/封闭原则? [英] Does Scala's pattern matching violate the Open/Closed Principle?
问题描述
如果我添加了一个新的case类，这是否意味着我需要搜索所有模式匹配代码并找出需要在哪里处理新类?我最近一直在学习该语言，当我读到一些支持和反对模式匹配的论据时，我对于应该在哪里使用它感到困惑.请参阅以下内容:
If I add a new case class, does that mean I need to search through all of the pattern matching code and find out where the new class needs to be handled? I've been learning the language recently, and as I read about some of the arguments for and against pattern matching, I've been confused about where it should be used. See the following:
骗局: Beust
在每种情况下，评论也都不错.那么模式匹配是令人兴奋的事情还是我应该避免使用的事物?实际上，我想答案是取决于您何时使用它"，但是有哪些积极的用例，有什么消极的用例呢?
The comments are pretty good in each case, too. So is pattern matching something to be excited about or something I should avoid using? Actually, I imagine the answer is "it depends on when you use it," but what are some positive use cases for it and what are some negative ones?
推荐答案
杰夫，我认为您有正确的直觉:这要视情况而定.
Jeff, I think you have the right intuition: it depends.
当您具有一组需要实现的相对固定的方法时，带有虚拟方法分派的面向对象的类层次结构会很好，但是许多潜在的子类可能会从层次结构的根部继承并实现这些方法.在这样的设置中，添加新的子类(只实现所有方法)相对容易，但是添加新的方法(要修改所有子类以确保它们正确地实现新方法)相对困难.
Object-oriented class hierarchies with virtual method dispatch are good when you have a relatively fixed set of methods that need to be implemented, but many potential subclasses that might inherit from the root of the hierarchy and implement those methods. In such a setup, it's relatively easy to add new subclasses (just implement all the methods), but relatively difficult to add new methods (you have to modify all the subclasses to make sure they properly implement the new method).
当您拥有属于数据类型的相对固定的类集时，具有基于模式匹配功能的数据类型是很好的，但是有许多潜在的功能可以对该数据类型进行操作.在这样的设置中，为数据类型添加新功能相对容易(仅在其所有类上进行模式匹配)，但是相对困难地添加属于数据类型的新类(您必须修改所有与之匹配的功能数据类型，以确保它们正确支持新类.
Data types with functionality based on pattern matching are good when you have a relatively fixed set of classes that belong to a data type, but many potential functions that operate on that data type. In such a setup, it's relatively easy to add new functionality for a data type (just pattern match on all its classes), but relatively difficult to add new classes that are part of the data type (you have to modify all the functions that match on the data type to make sure they properly support the new class).
面向对象方法的典型示例是GUI编程. GUI元素需要支持的功能很少(在屏幕上进行绘制是最低限度的要求)，但是始终会添加新的GUI元素(按钮，表格，图表，滑块等).模式匹配方法的典型示例是编译器.编程语言通常具有相对固定的语法，因此语法树的元素很少更改(如果有的话)，但是不断增加对语法树的新操作(更快的优化，更彻底的类型分析等).
The canonical example for the OO approach is GUI programming. GUI elements need to support very little functionality (drawing themselves on the screen is the bare minimum), but new GUI elements are added all the time (buttons, tables, charts, sliders, etc). The canonical example for the pattern matching approach is a compiler. Programming languages usually have a relatively fixed syntax, so the elements of the syntax tree will change rarely (if ever), but new operations on syntax trees are constantly being added (faster optimizations, more thorough type analysis, etc).
幸运的是，Scala可让您结合使用这两种方法.案例类既可以进行模式匹配，也可以支持虚拟方法分派.常规类支持虚拟方法分派，并且可以通过在相应的伴随对象中定义提取器来进行模式匹配.由程序员决定何时使用每种方法都合适，但是我认为两种方法都有用.
Fortunately, Scala lets you combine both approaches. Case classes can both be pattern matched and support virtual method dispatch. Regular classes support virtual method dispatch and can be pattern matched by defining an extractor in the corresponding companion object. It's up to the programmer to decide when each approach is appropriate, but I think both are useful.
这篇关于Scala的模式匹配是否违反了开放/封闭原则?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
