In the Polymorphism lesson (Module 3) you already used is Book book to check the actual type of a LibraryItem at run time, and in Switch Statements (Module 2) you got a first preview of switch expressions. Both ideas are part of a broader feature of modern C#: pattern matching, which lets you check not just the type of a value, but also its properties, its ranges, and logical combinations between conditions, all in a compact syntax. This lesson brings together pattern matching, switch expressions, nullable reference types, and a reminder about records, as the set of features that define the style of C# today, and applies them to classify and filter BiblioTech's items.

1. Reminder: type patterns with is
2. Property patterns: { Available: true }
3. Relational and logical patterns: and, or, not, >, <
4. Switch expressions: the evolution of the classic switch
5. Patterns in switch expressions: combining type and property
6. Nullable reference types: #nullable enable, ?, and the ! operator
7. Records as part of modern C#: a reminder and the positional pattern

In the Polymorphism lesson you already wrote code like this, using a type pattern:

item is Book book checks, at run time, whether item is (or inherits from) Book, and if it is, it automatically declares a new variable book of type Book, already converted, available inside the block. This is already pattern matching: a type pattern is the simplest of all the patterns C# offers, and from here the lesson introduces more expressive patterns that combine with it.

A property pattern checks the value of one or more properties of an object, with no need for an intermediate variable:

item is { Available: true } reads as "if item has an Available property equal to true." This pattern can be combined with a type pattern, checking both the concrete type and one of its properties at once:

Here, three things are checked at once in a single expression: that item is (at run time) a Book, that its Available is true, and, in addition, the already-converted variable book is obtained — all in one line that would previously have required a nested if.

Relational patterns compare a numeric value using the operators <, >, <=, >= directly inside a pattern:

Logical patterns combine several patterns with the keywords and, or, and not (instead of &&, ||, !, which are reserved for regular boolean expressions):

These patterns aren't limited to if: they can be used in any is expression, and — most commonly in modern code — inside a switch expression, the topic of the next section.

In the Switch Statements lesson (Module 2) you got a first preview of switch expressions: a way of writing a switch that returns a value directly, with no repeated case/break, using => for each possible result:

The most important difference for this lesson is the last row: while the classic switch only compares exact equality against constant values, a switch expression accepts any pattern from sections 1 through 3, which makes it the natural tool for classifying objects like BiblioTech's according to their actual type and their properties.

Here's how a LibraryItem is classified by combining type and property patterns inside a switch expression:

The order of the cases matters, just as in a classic switch: C# evaluates each pattern from top to bottom and runs the first one that matches. That's why Book { Available: true } must come before plain Book: if Book were the first case, it would always match before Available was even checked, and the more specific case would never be reached.

Filtering an entire catalog list reuses exactly the same pattern, this time inside a boolean expression with LINQ (which you'll study in depth in a later lesson of this module):

You already used Book? in the Polymorphism lesson (Book? castBook = firstItem as Book;) without pausing on why the ? was there. Modern C# lets you enable nullable reference types, a feature that makes the compiler distinguish, for reference types (class, not just string/int?), between "can never be null" and "can be null," warning you when the code doesn't respect that distinction.

It's enabled (many new .NET projects come with it enabled by default) with this directive at the top of the file:

With this directive active, a type like Book means "never null" unless it's explicitly declared as Book?:

The ! operator (called the null-forgiving operator) tells the compiler "trust me, I know this value isn't null here, even though its type is nullable," silencing the warning without adding any real check at run time:

It's important to understand that nullable reference types are, above all, a compiler aid at compile time (warnings, not hard errors in most cases): they don't prevent an actual null from arriving at run time if the ! operator is misused, but they help enormously in catching potential NullReferenceExceptions before running the program.

The last lesson of Module 3 introduced record, with LoanSummary as the example:

Records, together with pattern matching, switch expressions, and nullable reference types, are part of the set of features that define modern C#: they all share the goal of expressing more meaning with less code, and of catching more errors at compile time. A direct connection between records and pattern matching is the positional pattern, which deconstructs a record directly into variables, using the same order as its constructor:

LoanSummary(var bookTitle, var memberName, _) extracts the record's three positional properties into two new variables, discarding the third with _ (the same underscore you already know as the "default" case of a switch expression, here used as "I don't care about this value"). This automatic deconstruction ability is another advantage records provide "for free," with no extra code, thanks to their positional syntax.

• Forgetting the order in a switch expression with type patterns: just as with stacked case labels in a classic switch, a more general case placed before a more specific one "shadows" the second; always place the more restrictive patterns (Book { Available: true }) before the more general ones (Book).
• Confusing patterns' and/or/not with boolean expressions' &&/||/!: these are different syntaxes for different contexts; inside a pattern (is ..., or inside a switch expression's case), use the words and/or/not, not the symbolic operators.
• Enabling #nullable enable halfway through a project and expecting zero warnings: turning it on over existing code is normal (and expected) to surface warnings in places that need review; don't systematically ignore those warnings — review them one by one.
• Overusing the ! operator: using it to silence any warning without analyzing whether the value could really be null reintroduces, through the back door, the same NullReferenceException risk that nullable reference types are meant to prevent.
• Tip: prefer is not null over != null (and is null over == null) in modern code; besides being more readable, is can't be surprisingly overridden the way the == operator can be for specific types.

1. Write a method string Classify(LibraryItem item) that uses a switch expression with type and property patterns to return: "Available book" if it's a Book with Available: true, "Lent-out book" if it's a Book that isn't available, "Magazine" for any other Magazine case, and "Unknown" for any other type. Test it with an available Book, a lent-out one, and a Magazine.

2. Enable #nullable enable at the top of a test file. Write a method Book? FindByTitle(List<Book> books, string title) that returns the first book whose Title matches, or null if none is found. Call the method twice (with a title that exists and one that doesn't) and, in each case, check with is not null before accessing its properties.

3. Given a record LoanSummary(string BookTitle, string MemberName, DateTime LoanDate), create a sample object and use a positional pattern (is LoanSummary(var title, var name, var date)) to extract its three values into new variables and display them separately.

string Classify(LibraryItem item) => item switch
{
    Book { Available: true } => "Available book",
    Book => "Lent-out book",
    Magazine => "Magazine",
    _ => "Unknown"
};

Book availableBook = new Book("Hopscotch", "Julio Cortazar", "978-84-376-0495-4");
Book lentBook = new Book("Ficciones", "Jorge Luis Borges", "978-84-376-0496-1");
lentBook.Lend();
Magazine magazine1 = new Magazine("National Geographic", "Various authors", 302);

Console.WriteLine(Classify(availableBook)); // "Available book"
Console.WriteLine(Classify(lentBook));      // "Lent-out book"
Console.WriteLine(Classify(magazine1));     // "Magazine"

#nullable enable

Book? FindByTitle(List<Book> books, string title)
{
    foreach (Book book in books)
    {
        if (book.Title == title)
        {
            return book;
        }
    }
    return null;
}

List<Book> books = new List<Book>
{
    new Book("Hopscotch", "Julio Cortazar", "978-84-376-0495-4")
};

Book? found = FindByTitle(books, "Hopscotch");
if (found is not null)
{
    Console.WriteLine(found.Isbn); // Ok, inside the "if" it's already known not to be null
}

Book? notFound = FindByTitle(books, "Another title");
if (notFound is null)
{
    Console.WriteLine("The book was not found.");
}

record LoanSummary(string BookTitle, string MemberName, DateTime LoanDate);

LoanSummary summary = new LoanSummary("Hopscotch", "Ana Martinez", new DateTime(2026, 1, 10));

if (summary is LoanSummary(var title, var name, var date))
{
    Console.WriteLine($"Title: {title}");
    Console.WriteLine($"Member: {name}");
    Console.WriteLine($"Date: {date:yyyy-MM-dd}");
}

In this lesson you've extended the is and switch you already knew with type, property, relational, and logical patterns; you've learned to use switch expressions with those same patterns to classify objects compactly; you've enabled nullable reference types so the compiler helps you prevent null references; and you've seen records, already familiar from Module 3, deconstructed with a positional pattern. Together, all of this forms the idiomatic style of C# today.

Up to now, every BiblioTech example has worked with individual objects or, at most, with a makeshift List<LibraryItem> inside a single method. The next lesson takes a step back to introduce generics: the feature that makes List<T> possible in the first place, and that will let you write your own reusable classes and methods for any data type, before building, in the Collections lesson, the complete Library class.