C# 软件设计模式-创建型模式【5种】

        在软件开发的广袤领域中，C# 作为一种强大而广泛应用的编程语言，其软件设计模式扮演着至关重要的角色。软件设计模式是经过实践验证的解决方案，它们为构建高质量、可维护和可扩展的软件系统提供了坚实的基础。
        创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离，对用户隐藏了类的创建细节。每个创建型模式都通过采用不同的解决方案来回答三个问题：创建什么？由谁创建？何时创建？创建型模式就是用来解决对象实例化和使用客户端耦合的模式，可以让客户端和对象实例化独立变化，做到相互不影响。

一、单例模式

《单例模式：软件设计模式的独特策略》

        单例模式，作为一种经典的设计模式，其核心思想在于确保一个特定的类在整个应用程序的生命周期中仅存在一个实例。这看似简单的概念，却蕴含着深刻的意义和价值。
从其本质而言，单例模式的存在主要基于以下几方面的考量。首先，它能有效避免多个实例带来的资源竞争和不一致性问题。在某些关键场景中，确保只有一个对象来处理特定任务或管理关键资源，能够极大地提升系统的稳定性和可靠性。其次，它为全局访问提供了一个简洁而统一的方式，使得不同部分的代码可以方便地与该唯一实例进行交互。
在实现单例模式时，需要精心设计和巧妙处理。通常，通过私有化构造函数来阻止外部直接创建实例，同时提供一个公共的静态方法用于获取唯一的实例。这种方式既保障了单例的特性，又提供了必要的访问途径。

例如，以下是一个简单的 C# 中单例模式的实现示例：

class Singleton
{
    private static Singleton instance;
    private Singleton() {}

    public static Singleton GetInstance()
    {
        if (instance == null)
        {
            instance = new Singleton();
        }
        return instance;
    }
}

单例模式在众多软件系统中都有着广泛的应用。无论是配置管理、日志记录，还是全局状态的维护等，都能看到它的身影。它以其独特的方式为系统的架构和运行提供了坚实的基础。然而，我们也需认识到单例模式并非适用于所有情况。在某些复杂的分布式环境或高并发场景下，可能需要进一步考虑其适用性和可能带来的潜在问题。但不可否认的是，在恰当的场景中，单例模式展现出了其无与伦比的价值和重要性。总之，单例模式作为软件设计的重要策略之一，以其简洁而有力的方式，为我们构建高效、稳定的软件系统提供了宝贵的思路和方法。对其深入理解和恰当应用，将有助于我们在软件开发的征程中迈出更加坚实的步伐。

二、简单工厂模式

《简单工厂模式：软件设计中的简洁之美》

        简单工厂模式，顾名思义，提供了一种相对简单而直接的方式来创建对象。它的核心在于通过一个专门的工厂类，根据不同的条件或标识，创建出相应的具体产品对象。
        这种模式带来了诸多显著的优点。其一，它有效地将对象的创建逻辑集中在一处，使得代码结构更加清晰，易于维护和管理。通过将创建过程封装在工厂中，减少了客户端代码与具体产品类之间的直接耦合。其二，它为扩展产品系列提供了便利。当需要添加新的产品类型时，只需在工厂中进行相应的修改和扩展，而无需对大量的客户端代码进行调整。
        以一个简单的示例来说明，假设有不同类型的汽车产品，如轿车和越野车，我们可以通过简单工厂来创建它们：

interface ICar
{
    void Drive();
}

class Sedan : ICar
{
    public void Drive()
    {
        Console.WriteLine("Sedan is driving.");
    }
}

class SUV : ICar
{
    public void Drive()
    {
        Console.WriteLine("SUV is driving.");
    }
}

class CarFactory
{
    public ICar CreateCar(string type)
    {
        switch (type)
        {
            case "Sedan":
                return new Sedan();
            case "SUV":
                return new SUV();
            default:
                throw new ArgumentException("Invalid car type.");
        }
    }
}

        在这个例子中，通过 CarFactory 这个工厂类，根据传入的类型信息创建出相应的汽车对象。然而，简单工厂模式也并非完美无缺。它可能在产品类型较多且复杂的情况下，导致工厂类变得庞大而难以管理。但总体而言，在合适的场景中，简单工厂模式以其简洁高效的特性，为软件设计提供了一种实用的解决方案。
        总之，简单工厂模式以其独特的方式在软件设计中占据着重要的一席之地。它体现了一种简洁、灵活的设计思路，为我们构建具有良好架构的软件系统提供了有力的支持。对其深入理解和恰当运用，将有助于提升软件设计的质量和效率。

三、工厂方法模式

《工厂方法模式：灵活与可扩展的软件设计智慧》

        工厂方法模式构建在对对象创建过程的精心规划之上。它的核心思想是将产品的具体创建延迟到子类中，通过定义抽象的工厂方法，让各个具体的工厂子类来负责实际产品的生产。
        这种模式带来了诸多显著优势。其一，它极大地增强了系统的灵活性和可扩展性。当需要添加新的产品类型时，只需创建对应的工厂子类，而无需修改原有代码，有效降低了对现有系统的影响。其二，它进一步解耦了产品类和工厂类，使得两者可以独立地变化和发展。
        例如，在一个生产不同类型电器的场景中：

interface IElectricalAppliance
{
    void Operate();
}

class Television : IElectricalAppliance
{
    public void Operate()
    {
        Console.WriteLine("Television is working.");
    }
}

class Refrigerator : IElectricalAppliance
{
    public void Operate()
    {
        Console.WriteLine("Refrigerator is working.");
    }
}

abstract class Factory
{
    public abstract IElectricalAppliance CreateAppliance();
}

class TelevisionFactory : Factory
{
    public override IElectricalAppliance CreateAppliance()
    {
        return new Television();
    }
}

class RefrigeratorFactory : Factory
{
    public override IElectricalAppliance CreateAppliance()
    {
        return new Refrigerator();
    }
}

        在这里，不同的工厂子类负责生产相应的电器产品，而抽象的工厂类定义了统一的创建接口。尽管工厂方法模式在带来诸多好处的同时，也可能导致类的数量增加。但从整体架构和可维护性的角度来看，它所提供的优势远远超过其带来的这点复杂性。
        总之，工厂方法模式作为一种重要的设计模式，展现了软件设计在追求灵活性、可扩展性和可维护性方面的智慧与努力。它为我们构建复杂而高质量的软件系统提供了有力的工具和思路，值得我们深入研究和熟练运用。通过工厂方法模式，我们能够更好地应对不断变化的需求和挑战，创造出更具适应性和生命力的软件作品。

四、抽象工厂模式

《抽象工厂模式：构建复杂系统的精巧架构》

        在软件设计的广阔天地中，抽象工厂模式犹如一座坚实的桥梁，连接着不同层次的组件和功能。抽象工厂模式的核心在于提供了一个创建一系列相关或相互依赖对象的接口，而无需明确指定具体的类。它将具体产品的创建细节隐藏在抽象工厂及其子类中。这一模式带来了诸多显著益处。首先，它有助于保持系统在产品族层面的一致性。通过统一的抽象工厂来管理相关产品的创建，确保了这些产品之间的协调配合。其次，它增强了系统对于产品族扩展的适应性。当需要引入新的产品族时，可以相对容易地创建对应的抽象工厂子类，而不会对现有代码造成大规模的冲击。
        考虑一个生产不同品牌、不同类型电子产品的场景，例如：

interface IPhone
{
    void MakeCall();
}

interface ITablet
{
    void BrowseWeb();
}

abstract class ElectronicFactory
{
    public abstract IPhone CreatePhone();
    public abstract ITablet CreateTablet();
}

class BrandXFactory : ElectronicFactory
{
    public override IPhone CreatePhone()
    {
        return new BrandXPhone();
    }

    public override ITablet CreateTablet()
    {
        return new BrandXTablet();
    }
}

class BrandYFactory : ElectronicFactory
{
    public override IPhone CreatePhone()
    {
        return new BrandYPhone();
    }

    public override ITablet CreateTablet()
    {
        return new BrandYTablet();
    }
}

        在这个例子中，不同的电子工厂可以生产出属于特定品牌的手机和平板，实现了产品族的创建和管理。
        然而，抽象工厂模式也并非毫无挑战。它可能会导致系统的抽象层次增加，在一定程度上增加了理解和维护的难度。但总体而言，在面对复杂的、具有多个相关产品族的系统时，其优势往往更加突出。
        总之，抽象工厂模式作为一种高级的设计模式，在构建大型、复杂且具有高度可扩展性的软件系统中发挥着关键作用。它体现了软件设计在应对多样化和变化性方面的深刻思考和精巧策略，为我们提供了一种有力的架构手段，助力我们打造出更加优秀和强大的软件作品。对其深入理解和恰当运用，将有助于提升我们软件设计的水平和质量。

五、原型模式

《原型模式：高效对象复制的艺术》

        原型模式的核心在于利用已有的对象作为原型，通过克隆的方式快速创建新的实例。这种方式避免了从头开始创建对象的繁琐过程，极大地提高了效率。
        它带来了诸多显著优点。其一，能够在某些情况下显著减少对象创建的开销，尤其是当对象的初始化较为复杂时。其二，通过克隆原型对象，可以保持对象状态的一致性，减少潜在的错误。
        以一个图形绘制的场景为例：

interface IGraphic
{
    IGraphic Clone();
    void Draw();
}

class Circle : IGraphic
{
    private int radius;

    public Circle(int radius)
    {
        this.radius = radius;
    }

    public IGraphic Clone()
    {
        return new Circle(this.radius);
    }

    public void Draw()
    {
        Console.WriteLine($"Drawing a circle with radius {radius}");
    }
}

        在这里，通过克隆原型的圆对象，可以快速得到具有相同属性的新圆对象来进行绘制。
        然而，原型模式也并非完美无缺。它可能需要处理深克隆等复杂情况，以确保对象的完整复制。同时，如果原型对象的修改较为频繁，可能需要额外注意克隆对象与原型之间的同步问题。
        总之，原型模式以其独特的方式为软件设计提供了一种高效的对象创建手段。它在特定场景下展现出强大的优势，帮助我们更灵活、高效地构建和管理软件系统。深入理解和恰当运用原型模式，能让我们在面对复杂的对象创建需求时游刃有余，为软件的性能和可维护性增添一份有力的保障。

---

Singleton单例模式解决的是实体对象个数的问题。除了Singleton之外，其他创建模式解决的都是new所带来的耦合关系。FactoryMethod，AbstractFactory，Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。（其实原乡就是一个特殊的工厂类，他只是把工厂和实体对象耦合在一起了）。如果遇到“易变类”，起初的设计通过从Factory Method开始。当遇到更多的复杂变化是，在考虑重构为其他三种工厂模式（AbstractFactory，Builder，Prototype）。一般来说，如果可以使用FactoryMethod，那么一定可以使用Prototype。但是Prototype的使用情况一般是在类比较容易克隆的条件之上，如果每个类实现比较简单，都可以只用实现MemberwiseClone，没有引用类型的深拷贝，那么就更适合了。

---