The previous lesson polished BiblioTech's code style: names, comments, documentation, nullability. This lesson takes a step beyond style, toward design: how to organize the relationships between classes to solve problems that keep coming up, again and again, in any object-oriented project. A design pattern is precisely that — a proven solution to one of those recurring problems, not code you copy literally, but a way of thinking about the structure of the classes involved. You'll see three classic families of patterns and apply two of them directly to BiblioTech's domain: Factory Method to create library items, and Strategy to calculate late-return penalties. You'll also discover that one of the best-known behavioral patterns — Observer — has already been at work in BiblioTech for several modules, without anyone having named it until now.

1. What a design pattern is and why it matters
2. Creational patterns: Singleton and Factory Method
3. Structural patterns: Adapter and Decorator
4. Behavioral patterns: Strategy and Observer
5. Summary table: when to use each pattern
6. Example: Factory Method to create LibraryItems
7. Example: Strategy for penalty calculation policies

A design pattern isn't a library you install, nor new C# syntax: it's a conceptual template, documented and named, for solving a design problem that recurs across otherwise very different projects. The idea was popularized by the book Design Patterns (1994, the so-called "Gang of Four"), which cataloged twenty-three patterns grouped into three families:

Knowing these patterns matters for two practical reasons: first, they give you shared vocabulary — saying "this is an Observer" instantly communicates a whole structure to another developer, without having to explain it from scratch; second, they help you avoid reinventing, worse, a solution that's already proven and has well-known trade-offs. This isn't about forcing a pattern into every class you write — a pattern misapplied where it isn't needed adds unnecessary complexity — but about recognizing when the problem in front of you already has a named design solution.

Singleton guarantees that a class has a single instance throughout the entire application, and offers a global access point to it:

The private constructor prevents creating instances with new from outside the class; the only access route is the static Instance property, which creates the object the first time it's requested (??=, the null-coalescing assignment operator) and always returns that same reference afterward. Singleton is useful for shared global configuration, but it's worth using sparingly: overusing it makes unit testing harder (Lesson 4 of this module), because it introduces hidden global state that's difficult to replace with a test version.

Factory Method encapsulates the logic of which concrete class to create inside a dedicated method, instead of scattering calls to new ConcreteType(...) throughout the program. Whoever requests an object doesn't need to know the exact class it will receive, only the base type or common interface:

The code calling ItemFactory.Create doesn't write new Book(...) or new Magazine(...) directly: it delegates that decision to the factory, based on a simple string. This centralizes the "which concrete class matches each type" logic in a single place, instead of repeating it — with the risk of it drifting out of sync — at every point in the program that needs to create an item. Section 6 expands on this example in more detail.

Adapter adapts the interface of an existing class (often one that can't be modified) so it fits the interface the rest of the code expects. Imagine an external library catalog service that exposes its data with field names different from BiblioTech's:

ExternalCatalogAdapter inherits from LibraryItem and, internally, translates calls to GetBookTitle()/GetBookAuthor() on LegacyExternalCatalog into the constructor LibraryItem already expects. The rest of BiblioTech can treat an item coming from that external service exactly like one of its own Books or Magazines, without ever knowing LegacyExternalCatalog's original interface.

Decorator adds responsibilities to an object by wrapping it, without modifying its class or using inheritance for every possible combination of added behaviors:

NewLabelDecorator wraps any LibraryItem and adds the [NEW] prefix to its description, without touching either Book or Magazine, or needing a separate NewBook/NewMagazine class for every combination. Several decorators could be chained together (for example, one that adds [FEATURED] on top of this one) to combine behaviors flexibly.

Strategy encapsulates an interchangeable algorithm behind a common interface, so the concrete algorithm can be swapped at runtime without touching the code that uses it. Section 7 develops this in depth with Loan's penalty policies.

Observer defines a one-to-many dependency between objects: when one object (the subject) changes state, all of its observers are notified automatically, with no need for the subject to know them in advance. Revisit Library's LoanRegistered event, introduced in the Delegates and Events lesson from Module 4:

Without anyone having named it until now, this structure is the Observer pattern: Library is the subject, each method subscribed with += is an observer, and event is the specific mechanism C# offers to implement this pattern safely (recall the Delegates and Events lesson: event prevents invoking or replacing the list of subscribers from outside the class). It's common to find you've already used a design pattern without knowing it — recognizing it now, by name, helps you reason about it using the C# community's shared vocabulary, and to recognize the same structure the next time it shows up.

Picking ItemFactory back up from section 2, here's a more complete version reflecting how it would be used in BiblioTech when importing items from an external source (for example, a CSV file or a JSON response, Module 5) where the item type arrives as text:

If BiblioTech added a third item type in the future (for example, AudioBook), the only change needed would be adding a new case to ItemFactory.Create's switch; no other point in the program that already calls the factory would need to change.

BiblioTech needs to calculate a penalty when a loan is returned late. Instead of writing that logic directly inside Loan (which would force the class to change every time the penalty policy changed), Strategy extracts it into an interchangeable interface:

FixedPenalty always charges the same amount if there's a delay, no matter how many days; ProgressivePenalty charges more the more days late it is. Both implement the same IPenaltyPolicy interface, so they're interchangeable with each other. Loan receives the policy to apply without knowing the details of either implementation:

CalculatePenalty receives the policy as a parameter (IPenaltyPolicy policy): Loan doesn't know, or need to know, whether FixedPenalty, ProgressivePenalty, or a third policy added in the future (for example, one that waives the penalty for members with a certain tenure) is being applied. Switching policies — even at runtime, deciding which one to use based on some condition — requires no modification to Loan at all.

• Forcing a pattern where it isn't needed: applying Strategy for an if/else that will never change, or Decorator for a single variation that never combines with another, adds complexity with no real benefit. Patterns solve problems of variation and growth; if that problem doesn't exist, plain, simple code is the better option.
• Confusing Adapter with Decorator: both "wrap" an object, but for different purposes: Adapter translates an incompatible interface into the expected one; Decorator adds behavior to an interface that was already compatible from the start.
• Overusing Singleton for "anything global": Singleton makes unit testing harder (Lesson 4) because it introduces shared state that's difficult to replace with a test version. Lesson 3 of this module (Dependency Injection) offers, for most cases, a more flexible and more testable alternative.
• Tip: don't memorize all twenty-three patterns from the original catalog; it's enough to recognize, when a familiar problem shows up (creating objects based on a variable type, notifying several interested parties, swapping an algorithm), which pattern already solves exactly that problem.

1. Add a third case to ItemFactory.Create (section 6) for an "audiobook" type that creates an AudioBook : LibraryItem class (you may assume it already exists, with a constructor AudioBook(string title, string author, int durationMinutes)), interpreting additionalData as the duration in minutes.

2. Implement a third IPenaltyPolicy policy called NoPenalty, which always returns 0m regardless of the days late, and explain in one sentence what BiblioTech scenario it would make sense in.

public static LibraryItem Create(string type, string title, string author, string additionalData)
{
    return type.ToLower() switch
    {
        "book" => new Book(title, author, isbn: additionalData),
        "magazine" => new Magazine(title, author, issueNumber: int.Parse(additionalData)),
        "audiobook" => new AudioBook(title, author, durationMinutes: int.Parse(additionalData)),
        _ => throw new ArgumentException($"Unknown item type: '{type}'")
    };
}

class NoPenalty : IPenaltyPolicy
{
    public decimal CalculatePenalty(int daysLate) => 0m;
}

It would make sense, for example, for members with some kind of exemption (library staff, or a temporary promotion), where you want to reuse all of Loan.CalculatePenalty's logic without applying any real financial penalty.

In this lesson you've learned what a design pattern is and why it gives you shared vocabulary and proven solutions, seen Singleton and Factory Method (creational), Adapter and Decorator (structural), and Strategy and Observer (behavioral) — discovering that the latter had already been at work in Library.LoanRegistered since Module 4 — and applied Factory Method to centralize item creation and Strategy to make Loan's penalty policies interchangeable. The next lesson picks up in depth a mechanism that already appeared mentioned in passing across several of Module 7's interfaces (ASP.NET Core, Blazor, MAUI): dependency injection, which turns out, at its core, to be a systematic way of applying the same principle that makes Strategy possible — programming against interfaces, not concrete implementations — to the whole BiblioTech project.