C#设计模式全面入门指南

苏西苏西

于 2024-09-23 13:31:44 发布

阅读量905

点赞数 26

本文链接：https://blog.csdn.net/weixin_36328210/article/details/142482200

版权

本文还有配套的精品资源，点击获取

简介：设计模式是软件工程中的通用最佳实践，其在C#中的应用能提升软件的可复用性、可维护性和灵活性。该指南介绍设计模式的三大类别：创建型、结构型和行为型，并强调它们如何帮助开发者有效协作并避免重复劳动。书中详细探讨了23种设计模式的概念、实现以及C#中的应用实例。此外，提供了学习资源链接，包含课程、论坛和实战项目，帮助学习者深入理解C#设计模式。 Design Pattern

1. 设计模式的基本概念和在C#中的应用

设计模式是软件工程中用于解决常见问题的模板，它们是众多软件开发人员在长期实践中总结出的宝贵经验。在C#编程中，合理运用设计模式可以提升代码的可维护性、可读性和可扩展性，是构建健壮软件系统的基础。

设计模式主要分为三类：创建型模式、结构型模式和行为型模式。创建型模式涉及对象创建机制，结构型模式关注如何组合类和对象以获得更大的结构，行为型模式专注于对象之间的职责分配。

在C#中应用设计模式时，开发者需要深入理解每种模式的意图、结构和实现方式。例如，单例模式确保一个类只有一个实例，并提供全局访问点；工厂方法模式定义了一个创建对象的接口，让子类决定实例化哪一个类；适配器模式允许不兼容接口之间的合作。这些都是在C#开发中常用的设计模式，各有其独特的使用场景和优势。

1.1 设计模式的基本原则

单一职责原则（Single Responsibility Principle, SRP）: 一个类应该只有一个引起它变化的原因。
开闭原则（Open/Closed Principle, OCP）: 软件实体应当对扩展开放，对修改关闭。
里氏替换原则（Liskov Substitution Principle, LSP）: 子类型必须能够替换掉它们的基类型。
依赖倒置原则（Dependency Inversion Principle, DIP）: 高层模块不应该依赖低层模块，两者都应该依赖其抽象。
接口隔离原则（Interface Segregation Principle, ISP）: 不应该强迫客户依赖于它们不用的方法。

1.2 设计模式的分类

创建型模式

创建型模式专注于如何创建对象，主要解决对象的创建和组合的问题。例如：

单例模式 ：保证一个类只有一个实例，并提供一个全局访问点。
工厂方法模式 ：定义一个用于创建对象的接口，让子类决定实例化哪一个类。
抽象工厂模式 ：提供一个创建一系列相关或相互依赖对象的接口，无需指定它们具体的类。

结构型模式

结构型模式关注类和对象的组合。它们描述如何将类或对象结合在一起形成更大的结构。例如：

适配器模式 ：将一个类的接口转换成客户期望的另一个接口。
装饰器模式 ：动态地给一个对象添加一些额外的职责，而又不改变其结构。
代理模式 ：为其他对象提供一种代理以控制对这个对象的访问。

行为型模式

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象无法独立完成的任务。例如：

观察者模式 ：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
职责链模式 ：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。
策略模式 ：定义了一系列算法，并将每个算法封装起来，使它们可以互相替换，且算法的变化不会影响到使用算法的客户。

通过以上对设计模式的概述，我们可以开始深入探讨各个模式的细节以及在C#中的实现策略。随着章节的深入，我们将逐步揭示如何在实际开发中应用这些模式，以及它们如何帮助我们编写出更加优雅、可维护和可扩展的代码。

2. 创建型模式的种类和C#实现

2.1 单例模式

2.1.1 单例模式的概念和应用场景

单例模式（Singleton Pattern）是一种常见的设计模式，它主要目的是确保一个类仅有一个实例，并提供一个全局访问点。单例模式的类会自己创建这个唯一的实例，并提供一个方法来让其他对象访问这个实例。这种设计方式常用于管理系统的配置信息、日志记录器、线程池等场景。

应用场景包括： - 确保类只有一个实例，可以全局访问该实例，如配置管理器。 - 控制资源的访问，例如数据库连接池。 - 在应用中提供一个全局访问点，以方便后续扩展。

2.1.2 C#中实现单例模式的多种方法

在C#中，实现单例模式可以通过不同的方式。下面是一些常用的实现策略：

饿汉式

public sealed class Singleton 
{
    private static readonly Singleton instance = new Singleton();
    private Singleton() { }

    public static Singleton Instance
    {
        get { return instance; }
    }
}

饿汉式单例在类加载时就完成了初始化，保证了实例的唯一性。由于在类加载时就会完成初始化，因此是线程安全的。但同时如果这个类没有被使用也会占用一定的资源。

懒汉式

public sealed class Singleton
{
    private static Singleton instance;
    private static readonly object padlock = new object();

    Singleton() { }

    public static Singleton Instance
    {
        get 
        {
            lock (padlock)
            {
                if (instance == null)
                {
                    instance = new Singleton();
                }
                return instance;
            }
        }
    }
}

懒汉式单例模式在第一次调用实例时才创建实例。这种方式在C#中更常使用，因为它不会占用不必要的资源。然而，由于涉及线程安全问题，所以使用锁（ lock ）来保证实例的唯一性。

线程安全的懒汉式

public sealed class Singleton
{
    private static Singleton instance = null;
    private static readonly object padlock = new object();

    Singleton() { }

    public static Singleton Instance
    {
        get 
        {
            if (instance == null)
            {
                lock (padlock)
                {
                    if (instance == null)
                    {
                        instance = new Singleton();
                    }
                }
            }
            return instance;
        }
    }
}

线程安全的懒汉式单例模式通过双重检查锁定机制（Double-Check Locking），既实现了懒加载又保证了线程安全。这种方式在实例创建之后的访问效率接近饿汉式。

静态初始化器

public sealed class Singleton
{
    private static readonly Singleton instance = new Singleton();
    // 私有构造函数防止外部实例化
    private Singleton() { }

    public static Singleton Instance
    {
        get { return instance; }
    }
}

静态初始化器是C#特有的实现方式，通过编译器保证只初始化一次。由于它是由JIT在加载类时保证初始化的唯一性，所以也是线程安全的。

2.1.3 对单例模式的考量和最佳实践

在实现单例模式时，需要考虑以下几点：

确保构造函数是私有的，防止通过new操作符创建类的新实例。
考虑到应用程序的生命周期，决定是使用饿汉式还是懒汉式。
为了确保线程安全，应谨慎选择实现方式。在C#中，静态初始化器和线程安全的懒汉式是比较推荐的实现方式。
避免使用全局变量，以防止在复杂的应用程序中引入难以跟踪的依赖关系。

单例模式虽然简单，但在设计复杂的系统时，应谨慎使用。过早的优化往往会导致代码难以维护和扩展。单例模式适合于那些确实需要全局访问点的场景，而其他情况应考虑是否真的需要这种模式。

2.2 工厂方法模式

2.2.1 工厂方法模式的基本原理

工厂方法模式（Factory Method Pattern）是一种创建型设计模式，用于定义一个创建对象的接口，但让子类决定实例化哪一个类。工厂方法把实例化的工作推迟到子类中进行，这样做可以让创建过程更加灵活，让系统在不修改现有代码的情况下引入新的具体产品类。

该模式的主要参与者有：

Product：定义产品的接口或抽象类。
ConcreteProduct：实现产品接口的具体类。
Creator：声明工厂方法，它返回一个产品类型的对象。工厂方法可以被子类重写以创建对应的产品。
ConcreteCreator：重写工厂方法以返回ConcreteProduct的一个实例。

2.2.2 在C#中的具体应用示例

示例代码

// 产品接口
public interface IProduct
{
    void Operation();
}

// 具体产品A类
public class ConcreteProductA : IProduct
{
    public void Operation()
    {
        // 实现具体操作...
    }
}

// 具体产品B类
public class ConcreteProductB : IProduct
{
    public void Operation()
    {
        // 实现具体操作...
    }
}

// 创建者抽象类
public abstract class Creator
{
    // 工厂方法声明
    public abstract IProduct FactoryMethod();
}

// 具体创建者A
public class ConcreteCreatorA : Creator
{
    public override IProduct FactoryMethod()
    {
        return new ConcreteProductA();
    }
}

// 具体创建者B
public class ConcreteCreatorB : Creator
{
    public override IProduct FactoryMethod()
    {
        return new ConcreteProductB();
    }
}

使用场景分析

工厂方法模式允许系统在不修改现有代码的情况下引入新产品。例如，如果一个软件系统需要支持不同类型的数据库连接，可以使用工厂方法模式创建不同类型的数据库连接对象。

优缺点分析

优点： - 将对象的创建和使用分离，降低了代码之间的耦合。 - 客户端代码不需要关心具体产品类，只与抽象接口交互，增强了系统的可扩展性。

缺点： - 增加新的产品类型时，必须修改工厂类，这可能会违反开闭原则。

2.3 抽象工厂模式

2.3.1 抽象工厂模式的定义及其优势

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。这个超级工厂又称为“工厂的工厂”，其目的是提供一个接口以创建一系列相关或依赖对象，而无需指定它们具体的类。

抽象工厂模式的主要优点包括：

它能够确保同一工厂生产的对象互相匹配，因为这些对象都遵循同一设计约束。
产品族中的产品可以一起使用，这有利于保持代码的一致性和稳定性。
隔离具体类的创建，使得改变产品族中的产品较为容易。
当产品的具体类经常变动时，抽象工厂模式可以减少客户端代码和产品类之间的编译链接。

2.3.2 C#实现抽象工厂模式的策略与代码实例

示例代码

// 抽象产品A
public interface IAbstractProductA
{
    void OperationA();
}

// 抽象产品B
public interface IAbstractProductB
{
    void OperationB();
}

// 具体产品A1
public class ConcreteProductA1 : IAbstractProductA
{
    public void OperationA()
    {
        // 实现具体操作...
    }
}

// 具体产品A2
public class ConcreteProductA2 : IAbstractProductA
{
    public void OperationA()
    {
        // 实现具体操作...
    }
}

// 具体产品B1
public class ConcreteProductB1 : IAbstractProductB
{
    public void OperationB()
    {
        // 实现具体操作...
    }
}

// 具体产品B2
public class ConcreteProductB2 : IAbstractProductB
{
    public void OperationB()
    {
        // 实现具体操作...
    }
}

// 抽象工厂
public interface IAbstractFactory
{
    IAbstractProductA CreateProductA();
    IAbstractProductB CreateProductB();
}

// 具体工厂1
public class ConcreteFactory1 : IAbstractFactory
{
    public IAbstractProductA CreateProductA()
    {
        return new ConcreteProductA1();
    }

    public IAbstractProductB CreateProductB()
    {
        return new ConcreteProductB1();
    }
}

// 具体工厂2
public class ConcreteFactory2 : IAbstractFactory
{
    public IAbstractProductA CreateProductA()
    {
        return new ConcreteProductA2();
    }

    public IAbstractProductB CreateProductB()
    {
        return new ConcreteProductB2();
    }
}

使用场景分析

抽象工厂模式适用于创建一系列相关或相互依赖的对象。例如，一个UI库可能需要提供不同风格的按钮、文本框等控件，这些控件需要保持风格一致，因此可以使用抽象工厂模式。

优缺点分析

优点： - 抽象工厂模式可以在不修改现有代码的情况下，通过增加新的工厂类来增加新的产品族，满足开闭原则。

缺点： - 当产品族种类很多时，会导致工厂类的数量成倍增加，导致系统过于复杂。

通过本节的介绍，你已经了解了创建型模式中的单例模式、工厂方法模式和抽象工厂模式，以及它们在C#中的各种实现方式。下一节将继续探讨结构型模式的种类和在C#中的实现，包括适配器模式、装饰器模式和代理模式。

3. 结构型模式的种类和C#实现

3.1 适配器模式

3.1.1 适配器模式的定义与目的

适配器模式是一种结构型设计模式，它允许将一个类的接口转换成客户期望的另一个接口。适配器模式使得原本由于接口不兼容而无法一起工作的那些类可以一起工作。该模式的关键角色包括目标接口、适配器以及被适配者（即需要被适配的类）。

适配器模式的主要目的有两个： 1. 使得原本接口不兼容的类可以合作无间。 2. 对对象的接口进行解耦，提高组件的复用性。

3.1.2 C#代码中的适配器模式实现方法

在C#中实现适配器模式，通常需要创建一个新的适配器类，该类实现目标接口并包含一个被适配者的实例。下面是一个简单的实现示例：

// 被适配的类，它有一个不符合目标接口的遗留方法
class Adaptee
{
    public void LegacyOperation()
    {
        Console.WriteLine("Adaptee Operation");
    }
}

// 目标接口，定义了预期的方法
interface ITarget
{
    void Operation();
}

// 适配器，它实现目标接口并持有一个被适配者的引用
class Adapter : ITarget
{
    private Adaptee adaptee = new Adaptee();

    public void Operation()
    {
        // 调用被适配者的遗留方法，然后执行额外的操作以转换接口
        adaptee.LegacyOperation();
        Console.WriteLine("Adapter Operation");
    }
}

// 客户端代码，使用目标接口
class Client
{
    public void CallOperation(ITarget target)
    {
        target.Operation();
    }
}

// 客户端使用适配器的示例
class Program
{
    static void Main(string[] args)
    {
        Client client = new Client();
        ITarget adapter = new Adapter();
        client.CallOperation(adapter);
    }
}

在上面的示例中， Adaptee 类有一个名为 LegacyOperation 的方法，但它并不符合我们期望的 ITarget 接口。我们创建了一个适配器 Adapter 来桥接这两者之间的差异。通过在 Adapter 类中实现 ITarget 接口，并在 Operation 方法中调用 Adaptee 的 LegacyOperation 方法，我们为客户端提供了期望的接口。这样，即使 Adaptee 的内部实现发生了变化，也不会影响到使用 Adapter 的客户端代码。

3.1.2 适配器模式的C#实现分析

适配器模式将一个类的接口转换成客户期望的另一个接口，这样做可以让原本不兼容的接口能够协同工作。在实际应用中，我们常常会遇到新旧系统对接的场景，或者是第三方库不符合现有系统接口的情况。适配器模式提供了一个优雅的解决方案，通过添加一层适配逻辑来整合不同接口。

在实现适配器模式时，需要特别注意以下几点：

适配器应保持透明，即不应改变调用者原有接口的使用方式。
适配器的扩展性应良好，以适应未来可能出现的接口变化。
适配器类应尽量保持轻量，不应包含过多的业务逻辑，以避免造成难以维护的设计。

适配器模式在C#中是一种非常有用的模式，它帮助开发者以一种简洁的方式解决接口不兼容的问题。无论是与遗留系统进行集成，还是整合第三方库，适配器模式都提供了一个灵活且高效的解决方案。

4. 行为型模式的种类和C#实现

4.1 观察者模式

4.1.1 观察者模式的定义及其在C#中的实现

观察者模式是一种行为设计模式，允许对象之间的一对多依赖关系，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。该模式包含两个主要角色：主题（Subject）和观察者（Observer）。

在C#中实现观察者模式，我们通常定义一个接口或抽象类，表示“观察者”，它包含一个更新方法，用于在主题状态改变时获取通知。然后我们定义一个“主题”类，该类维护一个观察者列表，并在状态改变时通知所有观察者。

public interface IObserver
{
    void Update();
}

public class ConcreteObserver : IObserver
{
    public void Update()
    {
        // 更新逻辑
    }
}

public interface ISubject
{
    void RegisterObserver(IObserver o);
    void RemoveObserver(IObserver o);
    void NotifyObservers();
}

public class ConcreteSubject : ISubject
{
    private List<IObserver> observers = new List<IObserver>();
    private int state;

    public int State
    {
        get { return state; }
        set
        {
            state = value;
            NotifyObservers();
        }
    }

    public void RegisterObserver(IObserver o)
    {
        observers.Add(o);
    }

    public void RemoveObserver(IObserver o)
    {
        observers.Remove(o);
    }

    public void NotifyObservers()
    {
        foreach (var observer in observers)
        {
            observer.Update();
        }
    }
}

4.1.2 观察者模式在事件驱动编程中的应用

观察者模式在C#中的一个重要应用是事件驱动编程。在C#中，可以使用委托和事件来实现观察者模式。委托提供了一种引用方法的类型，而事件是一种特殊的多播委托，可以有一个或多个方法订阅它。当事件被触发时，所有订阅它的方法将按照顺序被调用。

public class Publisher
{
    // 声明一个事件
    public event EventHandler<EventArgs> RaiseEvent;

    // 触发事件
    public void DoWork()
    {
        // Do something useful here then...
        OnRaiseEvent(this, new EventArgs());
    }

    // 在这里保护事件的触发，以防止外部错误调用
    protected virtual void OnRaiseEvent(object sender, EventArgs e)
    {
        RaiseEvent?.Invoke(sender, e);
    }
}

public class Subscriber
{
    private readonly string name;

    public Subscriber(Publisher publisher, string name)
    {
        publisher.RaiseEvent += HandleEvent;
        this.name = name;
    }

    private void HandleEvent(object sender, EventArgs e)
    {
        Console.WriteLine($"Event handled by {name}");
    }
}

事件和委托允许我们创建一个松耦合系统，在这种系统中，事件发布者无需知道订阅者。这使得添加和移除事件处理程序变得非常简单，同时也使得代码更加模块化。

4.2 职责链模式

4.2.1 职责链模式的概念和设计意图

职责链模式是一种行为设计模式，它允许将请求沿着处理者链传递，直到有一个对象处理它为止。这种模式通过给多个对象处理请求的机会，从而解耦请求的发送者和接收者。

职责链模式的关键在于，一个请求可以被多个对象中的任意一个接收并处理，但每个处理者只需要处理自己能处理的请求，并将不能处理的请求转发给链条中的下一个处理者。

4.2.2 在C#中构建职责链模式的方法和案例分析

在C#中实现职责链模式通常涉及到创建一个处理器接口或抽象类，它包含一个方法用于处理请求，并且可以设置下一个处理器。

public interface IHandler
{
    IHandler SetNext(IHandler handler);
    object Handle(object request);
}

public abstract class Handler : IHandler
{
    protected IHandler successor;

    public IHandler SetNext(IHandler handler)
    {
        this.successor = handler;
        return handler;
    }

    public virtual object Handle(object request)
    {
        if (this.successor != null)
        {
            return successor.Handle(request);
        }
        else
        {
            return null; // 没有处理器可以处理请求
        }
    }
}

public class ConcreteHandler1 : Handler
{
    public override object Handle(object request)
    {
        if (request is int && (int)request < 0)
        {
            // 处理请求
            Console.WriteLine("ConcreteHandler1 handled: " + request);
            return request;
        }
        else
        {
            return base.Handle(request);
        }
    }
}

public class ConcreteHandler2 : Handler
{
    public override object Handle(object request)
    {
        if (request is int && (int)request >= 0)
        {
            // 处理请求
            Console.WriteLine("ConcreteHandler2 handled: " + request);
            return request;
        }
        else
        {
            return base.Handle(request);
        }
    }
}

在实际应用中，职责链可以用于创建分层的处理流程，例如审批流程、日志记录系统、异常处理系统等。

4.3 策略模式

4.3.1 策略模式的介绍和使用场景

策略模式是一种行为设计模式，它定义一系列算法，并使它们可以相互替换使用，从而将算法的定义与使用算法的对象分离。策略模式让算法的变化独立于使用算法的客户。

策略模式特别适用于一个类在其行为中拥有多种算法变体，而这些算法经常需要在运行时切换。通过策略模式，可以避免在类内部使用条件语句（如if-else）来选择算法。

4.3.2 C#实现策略模式的代码结构和优势

在C#中实现策略模式，我们通常会定义一个策略接口，然后创建多个实现了这个接口的具体策略类。最后，客户端代码可以动态地选择使用哪个策略对象。

public interface IStrategy
{
    void AlgorithmInterface();
}

public class ConcreteStrategyA : IStrategy
{
    public void AlgorithmInterface()
    {
        // 算法 A 实现
    }
}

public class ConcreteStrategyB : IStrategy
{
    public void AlgorithmInterface()
    {
        // 算法 B 实现
    }
}

public class Context
{
    private IStrategy strategy;

    public Context(IStrategy strategy)
    {
        this.strategy = strategy;
    }

    public void SetStrategy(IStrategy strategy)
    {
        this.strategy = strategy;
    }

    public void AlgorithmInterface()
    {
        strategy.AlgorithmInterface();
    }
}

策略模式的优势在于它提高了算法的灵活性和可重用性，使得算法可以独立于使用它们的客户端而变化。它还有利于单元测试，因为可以单独测试每一个策略。

以上就是在C#中实现行为型模式的几种方式，它们都能够显著地提高代码的清晰度和可维护性。

5. 设计模式对代码可读性和可扩展性的提升

设计模式在软件工程中占据着举足轻重的地位，它们不仅帮助开发者组织代码，而且对于提高代码的可读性和可扩展性起到了重要作用。本章节将重点讨论设计模式是如何提升代码质量的，并提供实例演示设计模式在实际开发中的应用。

5.1 设计模式对代码可读性的影响

5.1.1 设计模式提高代码可读性的原理

设计模式通过标准化的接口和结构化的设计，使得代码的意图和结构更加清晰。它们提供了一组共通的术语和模式，让团队成员之间无需大量解释就能理解代码的用途。例如，使用工厂模式可以将对象创建过程封装起来，使得对象的使用者不需要关注对象是如何被创建的，从而减少了代码中的复杂性，并提高了可读性。

5.1.2 具体模式对代码清晰度的贡献分析

以单例模式为例，它确保一个类只有一个实例，并提供一个全局访问点。这样的模式使得其它部分的代码不用关心这个类的实例是如何创建和管理的，它们只需要通过一个公共的访问点来获取这个类的唯一实例即可。单例模式的实现，让类的实例化变得透明，提高了代码的整洁度和可读性。

5.2 设计模式对代码可扩展性的贡献

5.2.1 设计模式增强系统扩展性的机制

设计模式常常通过解耦合和减少硬编码依赖来增强系统的扩展性。例如，策略模式允许算法的独立变化，当需要引入新的算法时，可以不改变现有的系统结构。这种松耦合的设计让系统能够更容易适应需求的变化，同时降低新功能引入时的维护成本。

5.2.2 实例演示设计模式如何支持系统的未来变化

考虑一个购物车系统，如果使用策略模式来处理支付方式，那么在未来增加新的支付方式（如信用卡支付、电子钱包等）时，我们只需要添加新的支付策略类而不需要修改原有代码。这样不仅使得系统易于扩展，而且使得支付方式的变更更加灵活。

public interface IPaymentStrategy
{
    void ProcessPayment(decimal amount);
}

public class CreditCardStrategy : IPaymentStrategy
{
    public void ProcessPayment(decimal amount)
    {
        // Payment logic for credit card
    }
}

public class EWalletStrategy : IPaymentStrategy
{
    public void ProcessPayment(decimal amount)
    {
        // Payment logic for electronic wallet
    }
}

public class ShoppingCart
{
    private List<Product> products = new List<Product>();
    private IPaymentStrategy paymentStrategy;

    public ShoppingCart(IPaymentStrategy paymentStrategy)
    {
        this.paymentStrategy = paymentStrategy;
    }

    public void AddItem(Product item)
    {
        products.Add(item);
    }

    public void Checkout()
    {
        paymentStrategy.ProcessPayment(this.GetTotalPrice());
    }

    private decimal GetTotalPrice()
    {
        return products.Sum(p => p.Price);
    }
}

5.3 设计模式的合理选择与应用

5.3.1 如何根据需求选择合适的设计模式

选择设计模式时，首先应理解设计模式背后的设计目的和原则。例如，如果项目需要在运行时动态地选择算法，策略模式是一个好选择；如果需要管理一个对象的生命周期，那么单例模式可能更加适用。其次，需权衡设计模式的利弊，并考虑团队的熟悉程度以及现有系统的限制。

5.3.2 结合C#语言特性综合应用设计模式

C#语言特性如委托、接口和继承等为设计模式提供了良好的支持。开发者在应用设计模式时，应该充分利用这些语言特性。例如，在实现观察者模式时，可以利用C#的事件和委托机制，这样可以使事件订阅和通知变得更简单和直观。

public class EventPublisher
{
    public event EventHandler<ProductEventArgs> ProductAdded;

    public void AddProduct(Product product)
    {
        // Add the product logic

        // Raise the event
        ProductAdded?.Invoke(this, new ProductEventArgs { Product = product });
    }
}

public class ProductEventArgs : EventArgs
{
    public Product Product { get; set; }
}

public class Subscriber
{
    public void OnProductAdded(object sender, ProductEventArgs e)
    {
        Console.WriteLine($"New product added: {e.Product.Name}");
    }
}

在本章中，我们探讨了设计模式如何提升代码的可读性和可扩展性，以及如何在C#中根据实际需求合理选择和应用这些模式。设计模式不仅是一套理论，更是实践中的工具，它们能够帮助开发者编写出更加优雅、易于维护的代码。随着实践的深入，开发者将会更好地理解设计模式的价值，并能够灵活运用这些模式来解决各种复杂的问题。

本文还有配套的精品资源，点击获取