Chapter 12 — Deconstruction and pattern matching

Purpose of this chapter: get comfortable with deconstruction (tuples and custom Deconstruct) and pattern matching (type/constant/var patterns, is, and switch) so you can write clearer branching logic and explain compiler behavior in interviews.

12.1 Deconstruction of tuples

Deconstruction lets you unpack a tuple into multiple variables:

var (x, y) = (10, 20);

12.1.1 Deconstruction to new variables

• Declares new locals on the left-hand side.

12.1.2 Assigning into existing targets

You can assign into existing variables/properties (be careful about mutability and struct copies).

12.1.3 Details of tuple deconstruction

Interview nuance:

• Deconstruction is compile-time; it maps positions/elements and emits assignments.

12.2 Deconstruction of non-tuple types

Types can support deconstruction by defining a Deconstruct method.

12.2.1 Instance Deconstruct methods

Example idea:

• Domain type exposes a small “view” of itself for unpacking.

12.2.2 Extension Deconstruct methods and overloading

You can add deconstruction via extension methods, but:

• Use sparingly; it can hide behavior and surprise readers.

12.2.3 How the compiler handles Deconstruct

Practical mental model:

• The compiler looks for an applicable Deconstruct(out ...) method.
• It calls it and assigns outputs to the left-hand side targets.

12.3 Introduction to pattern matching

Pattern matching makes conditionals more declarative:

• “Check the shape and bind parts of it” in one expression.

12.4 Patterns available in C# 7.0

12.4.1 Constant patterns

Match specific constants:

• Great for sentinel values, enums, and known cases.

12.4.2 Type patterns

Match and bind with a type check:

if (obj is Customer c) { /* use c */ }

12.4.3 The var pattern

var x binds the value (often used for readability or to force a name at a point in an expression).

12.5 Patterns with the is operator

is becomes a combined “test + assign” in one place.

Interview trap:

• Understand variable scope: the pattern variable is in scope only where it’s definitely assigned (depends on the expression structure).

12.6 Patterns with switch statements

Pattern-based switches can replace long if/else chains.

12.6.1 Guard clauses (when)

Guards let you add additional conditions per case.

12.6.2 Variable scope for case labels

Be careful with:

• Reusing variable names across cases.
• Understanding where the variable is in scope.

12.6.3 Evaluation order

Cases are typically evaluated top-to-bottom; ordering matters when patterns overlap.

12.7 Thoughts on usage

12.7.1 Spotting deconstruction opportunities

Good opportunities:

• Returning multiple values from parsing/lookup logic.
• Unpacking “coordinate-like” values.

12.7.2 Spotting pattern matching opportunities

Good opportunities:

• Branching based on runtime type + additional conditions.
• Avoiding repeated casts/null checks.

Guideline:

• Prefer patterns when they make the branching more explicit and reduce duplication—not just because they’re new syntax.