Scala pattern matching 3 The core function of pattern matching is to deconstruct

Http://www.artima.com/scalazine/articles/pattern_matching.html
This article is a Odersky talk about pattern matching in Scala, and I did part of the fragment translation (not coherent):

Patterns can be nested, like nested expressions, and you can define deep patterns, usually a pattern that looks like an expression. It's basically the same kind of thing.
It looks like a complex object tree construction expression, just missing the new keyword. In fact, in Scala, when you construct an object, you don't need the new keyword.
You can then replace the actual objects in the object tree with variable-position characters in some places.

In essence, pattern matching is necessary when you need to construct an object graph externally, because you cannot add methods to these objects
There are many examples of scenarios where XML is one, and all parsed data falls into different classifications.
For example, a standard scenario is when you use a compiler to parse an abstract syntax tree for pattern matching to be necessary.

Deconstructed objects (De-constructing objects)
Bill Venners: You say the pattern is like an expression, but it's more like "inverse expression," unlike inserting a value and getting the result (the process of constructing an object), you put a value, and when it matches, a string of values bounces out.
Martin Odersky: Yes, it's really a reverse construct, and I can construct the object through a nested constructor. I have a method with some parameters that can construct the responsible object structure through these parameters. Pattern matching is just the opposite, it pulls out the parameters originally used to construct the object from a complex object structure.

Two directions for scalability (two directions of extensibility)

Another concept of extensibility is that the data structure is relatively fixed and you don't want to change it, but the action you want to use is open. You always want to add a new action.
A typical example is a compiler, a compiler that expresses your program with a syntax tree, as long as you don't change your language, the syntax tree doesn't change, it's always the same tree
But the compiler wants this syntax tree to change every day. Tomorrow you might think of a new optimization in the traversal tree phase.

So, the way you want to do this is to manipulate the definition outside of your syntax tree, or you'll have to constantly add new methods

The right direction for this job depends on the way you want to expand in that direction, and if you want to extend the new data, you choose the Classic object-oriented implementation through the virtual method call. If you want to keep the data fixed and expand the new operation, the mode is more appropriate.
In fact, there is a design pattern, not confused with pattern matching, called "visitor pattern" in object-oriented program, can also be used in object-oriented way to express pattern matching, based on virtual method delegated.

But the actual use of the visitor model is very cumbersome, not as easy as pattern matching to do a lot of things. You should end the cumbersome vistors, while also proving in modern virtual machine technology that Vistor mode is far from being valid for pattern matching. For all these reasons, I think a set of rules should be defined for pattern matching

PS, the previous period of time Wang Yin students in a critical design model of an article, referred to visitor mode is pattern matching.
You can compare the Scala language with case class/extractor to support pattern matching at the language level, with code differences when the same effect is achieved by visitor mode.

Transferred from: http://ifeve.com/pattern-matching-3/

Scala pattern matching 3 The core function of pattern matching is to deconstruct