简介：工厂方法模式作为面向对象设计模式的一种，通过抽象工厂和具体工厂子类的实现来创建对象，遵循了“开闭原则”。在C#中，工厂方法模式可使用接口或抽象类来实现。文中提供了两个应用案例：简单工厂方法模式和多层工厂方法模式，详细介绍了如何在C#中根据不同的设计需求创建具体的产品实例。此外，还探讨了工厂方法模式适用的场景和它对代码质量的提升作用，以及与其他设计模式组合使用的可能性。
1. 工厂方法模式概念与原则
工厂方法模式是一种创建型设计模式，它通过定义一个用于创建对象的接口，让子类决定实例化哪一个类。这种模式使得一个类的实例化延迟到了子类。工厂方法模式用于解决简单工厂模式中违反开闭原则的问题，即当添加新的产品时，需要修改工厂类的判断逻辑，违背了开闭原则。
工厂方法模式遵循了以下设计原则：
1. 开闭原则：软件实体应当对扩展开放，对修改关闭。
2. 依赖倒置原则：要依赖于抽象，不要依赖于具体类。
3. 单一职责原则：一个类应该只有一个引起它变化的原因。
在工厂方法模式中，抽象工厂（Creator）类声明了工厂方法，该方法返回一个产品（Product）类型的对象。具体工厂（ConcreteCreator）类实现了工厂方法，创建并返回一个具体产品（ConcreteProduct）的实例。
通过这种方式，工厂方法模式实现了对产品创建过程的封装和抽象，使得创建逻辑可以灵活变化而不影响客户端代码。
// 抽象工厂类
public abstract class Creator
{
public abstract Product FactoryMethod();
}
// 具体工厂类
public class ConcreteCreator : Creator
{
public override Product FactoryMethod()
{
return new ConcreteProduct();
}
}
// 抽象产品类
public abstract class Product
{
}
// 具体产品类
public class ConcreteProduct : Product
{
}
在上述代码中， Creator 类定义了 FactoryMethod ，而 ConcreteCreator 类具体实现该方法，生产出具体的 ConcreteProduct 对象。这种方式有效地分离了对象的创建逻辑和使用逻辑，增加了系统的可扩展性和维护性。
2. C#中实现工厂方法模式的方式
2.1 工厂方法模式在C#中的基础实现
2.1.1 创建抽象工厂类和具体工厂类
在C#中实现工厂方法模式的第一步是定义一个抽象工厂类，它声明了创建产品对象的方法，并将其定义为抽象方法。每个具体工厂类都负责创建一个或多个具体产品类的实例。
下面是一个简单的抽象工厂类和具体工厂类的示例：
// 抽象工厂类
public abstract class Factory
{
public abstract Product CreateProduct();
}
// 具体工厂类A
public class ConcreteFactoryA : Factory
{
public override Product CreateProduct()
{
return new ConcreteProductA();
}
}
// 具体工厂类B
public class ConcreteFactoryB : Factory
{
public override Product CreateProduct()
{
return new ConcreteProductB();
}
}
在上述代码中， Factory 是抽象工厂类，包含一个抽象方法 CreateProduct 。 ConcreteFactoryA 和 ConcreteFactoryB 是两个具体工厂类，它们分别实现了 CreateProduct 方法，用于创建不同的产品实例。
2.1.2 实现产品接口和具体产品类
产品接口定义了产品类所必须实现的方法，而具体产品类则实现了这些接口方法。一个抽象工厂通常会关联一个产品族，即一组实现了相同接口的产品。
// 产品接口
public interface Product
{
void Operation();
}
// 具体产品类A
public class ConcreteProductA : Product
{
public void Operation()
{
Console.WriteLine("ConcreteProductA Operation");
}
}
// 具体产品类B
public class ConcreteProductB : Product
{
public void Operation()
{
Console.WriteLine("ConcreteProductB Operation");
}
}
在上述代码中， Product 是产品接口，定义了一个 Operation 方法。 ConcreteProductA 和 ConcreteProductB 是具体的产品类，它们都实现了 Product 接口的 Operation 方法。
2.2 高级特性在工厂方法模式中的应用
2.2.1 延迟加载
延迟加载是工厂方法模式中常见的一种优化手段，它允许在真正需要时才创建对象，从而节省资源并提高性能。
public class LazyLoadingFactory : Factory
{
private Product product;
private bool isProductCreated;
public override Product CreateProduct()
{
if (!isProductCreated)
{
product = new ConcreteProductB();
isProductCreated = true;
}
return product;
}
}
在上述代码中， LazyLoadingFactory 使用了C#的 Lazy<T> 类来实现延迟加载。只有当第一次调用 CreateProduct 方法时，具体的产品实例才会被创建。
2.2.2 依赖注入
依赖注入（DI）是一种设计模式，用于实现控制反转（IoC）的原则。它允许将依赖关系从创建它们的代码中解耦出来。在工厂方法模式中，依赖注入可以帮助我们提供不同的实现。
public interface IProductDependency
{
void DoSomething();
}
public class ConcreteProductWithDependency : Product
{
private readonly IProductDependency dependency;
public ConcreteProductWithDependency(IProductDependency dependency)
{
this.dependency = dependency;
}
public override void Operation()
{
dependency.DoSomething();
Console.WriteLine("ConcreteProductWithDependency Operation");
}
}
public class Dependency : IProductDependency
{
public void DoSomething()
{
Console.WriteLine("Dependency is doing something.");
}
}
// 使用时
var dependency = new Dependency();
var product = new ConcreteProductWithDependency(dependency);
在这个例子中， ConcreteProductWithDependency 接受一个 IProductDependency 接口的实例作为依赖，并在 Operation 方法中使用它。这使得 ConcreteProductWithDependency 与 Dependency 的实现解耦。
2.2.3 泛型的使用
在工厂方法模式中使用泛型可以提高代码的复用性，并且可以使工厂方法更加灵活。
public class GenericFactory<T> where T : Product, new()
{
public T CreateProduct()
{
return new T();
}
}
// 使用时
var factory = new GenericFactory<ConcreteProductA>();
var product = factory.CreateProduct();
在这个例子中， GenericFactory<T> 是一个泛型工厂类，它接受任何继承自 Product 的类型参数。这样，只需要一个工厂类就可以创建所有的产品类型。
通过这些高级特性的应用，工厂方法模式在C#中的实现变得更加灵活、可扩展且高效。接下来，我们将探讨简单工厂方法模式的应用案例，以便更好地理解这些概念在实际开发中的运用。
3. 简单工厂方法模式应用案例
3.1 简单工厂方法模式的定义和结构
3.1.1 简单工厂模式的组成
简单工厂模式（Simple Factory）是一种创建型设计模式，它提供了一种创建对象的最佳方式。在简单工厂模式中，工厂类根据传入的参数，决定创建出哪一种产品类的实例。
在简单工厂模式中，通常包含以下角色：
- 工厂（Factory） ：负责创建所有产品。
- 抽象产品（Product） ：产品的接口或抽象类，定义产品的公共方法。
- 具体产品（Concrete Product） ：具体产品的类，实现抽象产品的接口或继承抽象类。
一个简单的例子是创建一个计算器工厂，它可以生成加法、减法、乘法和除法计算器对象。
3.1.2 与工厂方法模式的对比
简单工厂模式与工厂方法模式的主要区别在于它们处理类结构的方式和目的。简单工厂模式使用一个工厂类来生成所有产品，而工厂方法模式则通过不同的工厂子类来生成相应的产品。
简单工厂模式适用于产品种类较少的情况，工厂方法模式则在产品种类较多、产品层次结构复杂时使用。工厂方法模式通过增加更多的工厂类来实现解耦和扩展。
3.2 简单工厂方法模式在实际开发中的运用
3.2.1 实例化对象的控制
在简单工厂模式中，工厂类是创建对象的唯一入口点。这种设计可以隐藏创建逻辑，使得客户代码不需要了解不同对象是如何创建的。例如，创建一个计算器对象：
public class CalculatorFactory
{
public static ICalculator GetCalculator(string operation)
{
if (operation.Equals("add"))
return new AddCalculator();
else if (operation.Equals("subtract"))
return new SubtractCalculator();
else if (operation.Equals("multiply"))
return new MultiplyCalculator();
else if (operation.Equals("divide"))
return new DivideCalculator();
else
throw new ArgumentException("Invalid operation");
}
}
3.2.2 简单工厂方法模式的优缺点分析
简单工厂模式的优点包括：
- 客户端与具体产品的实现无关，这使得更换产品变得容易。
- 单一职责原则：工厂负责所有对象的创建，从而避免创建对象的代码分散在客户端。
缺点则在于：
- 扩展性受限：一旦添加新的产品类型，就需要修改工厂类，违反了开闭原则。
- 单一工厂实例：如果系统中有多个工厂类，那么很难扩展。
表格：简单工厂模式与工厂方法模式对比
| 特性 | 简单工厂模式 | 工厂方法模式 |
|---|---|---|
| 创建逻辑 | 所有产品的创建逻辑集中在单个工厂类中 | 每个具体工厂负责创建特定的产品 |
| 扩展性 | 添加新产品类型时需要修改工厂类 | 新增产品时，只需增加新的工厂子类 |
| 开闭原则 | 不满足（修改工厂类破坏开闭原则） | 满足 |
| 类的数量 | 相对较少 | 会更多，每种产品一个工厂类 |
简单工厂模式在实际开发中可以处理简单对象创建问题，但它不适合复杂场景。对于需要频繁更新和扩展的系统，工厂方法模式或更高级的抽象工厂模式可能是更好的选择。
4. 多层工厂方法模式应用案例
4.1 多层工厂方法模式的架构设计
4.1.1 分层的目的和原则
在多层工厂方法模式中，分层的目的是为了将工厂的创建逻辑进一步抽象，使得工厂可以根据不同的维度来创建产品。这样做可以增强系统的灵活性和可扩展性，同时也便于维护和管理。
分层原则通常遵循以下几个关键点：
1. 单一职责原则 ：确保每个工厂层只负责创建一种类型的产品。
2. 依赖倒置原则 ：高层模块不应该依赖低层模块，它们都应该依赖抽象。
3. 开闭原则 ：软件实体应当对扩展开放，对修改关闭。
4.1.2 分层工厂方法模式的实现步骤
多层工厂方法模式的实现步骤涉及创建抽象工厂、具体工厂、产品以及对应的分层工厂。以下是实现的基本步骤：
- 定义抽象工厂接口 ：声明创建抽象产品的工厂方法。
- 创建具体工厂类 ：为每个产品系列创建具体工厂类。
- 定义抽象产品 ：声明产品对象的接口。
- 创建具体产品类 ：实现抽象产品接口的具体产品类。
- 构建分层工厂 ：根据需求构建不同层次的工厂类，实现复杂产品的分层创建。
4.2 多层工厂方法模式的实战演练
4.2.1 实际案例分析
假设我们要设计一个多层工厂方法模式来创建不同类型的商品，比如水果、蔬菜和肉类。每个类型又可以进一步细分为多种商品。例如，水果可以分为苹果、香蕉等。
首先，定义抽象工厂接口：
public interface IFruitFactory
{
Fruit Create();
}
public interface IVegetableFactory
{
Vegetable Create();
}
public interface IMeatFactory
{
Meat Create();
}
然后，创建具体工厂类来生产具体的产品：
public class AppleFactory : IFruitFactory
{
public Fruit Create()
{
return new Apple();
}
}
public class BananaFactory : IFruitFactory
{
public Fruit Create()
{
return new Banana();
}
}
// 类似地，为蔬菜和肉类定义对应的工厂类。
接着，构建分层工厂：
public class FoodFactory
{
public IFruitFactory FruitFactory { get; set; }
public IVegetableFactory VegetableFactory { get; set; }
public IMeatFactory MeatFactory { get; set; }
public FoodFactory(IFruitFactory fruitFactory, IVegetableFactory vegFactory, IMeatFactory meatFactory)
{
FruitFactory = fruitFactory;
VegetableFactory = vegFactory;
MeatFactory = meatFactory;
}
public Fruit CreateFruit(string fruitType)
{
switch (fruitType)
{
case "Apple":
return FruitFactory.Create();
case "Banana":
return FruitFactory.Create();
// 更多分支处理其他水果类型。
default:
throw new ArgumentException("Invalid fruit type");
}
}
// 类似地，可以添加 CreateVegetable 和 CreateMeat 方法。
}
4.2.2 多层工厂方法模式的优化策略
在实际应用中，多层工厂方法模式可能会变得相当复杂，特别是在产品种类繁多的情况下。优化策略可以从以下几个方面考虑：
- 使用配置文件 ：减少硬编码，通过配置文件管理产品和工厂之间的映射关系。
- 代理模式 ：在工厂类之间使用代理模式来简化调用链。
- 延迟初始化 ：避免不必要的对象创建，当真正需要某个产品实例时才进行初始化。
- 缓存机制 ：对已经创建的对象进行缓存，避免重复创建。
例如，可以采用配置文件管理产品类型：
{
"FruitFactory": "AppleFactory",
"VegetableFactory": "TomatoFactory",
"MeatFactory": "BeefFactory"
}
在软件中解析这个配置文件，并根据配置来动态创建工厂实例。这样做的好处是可以灵活地更改产品的创建逻辑，而无需改动代码本身，提高了代码的可维护性。
5. 工厂方法模式的适用场景
工厂方法模式（Factory Method Pattern）是一种创建型设计模式，它提供了一个创建对象的最佳方式。在这一章节中，我们将深入探讨工厂方法模式的适用条件以及它在实际开发中的一些典型应用场景。
5.1 工厂方法模式的适用条件
5.1.1 当前系统的类结构设计
工厂方法模式适用于那些类的创建逻辑可能变化，或者类的使用者不想直接创建类的场景。当系统中的某个类存在多个可能的子类时，如果创建逻辑固定不变，那么通常更适合用简单工厂模式。但如果子类类型经常变化，或添加新的子类是常态，那么工厂方法模式会更加灵活。
工厂方法模式允许类将创建对象的细节委托给子类。这意味着如果一个类只知道其产品的接口，而不知道具体的实现细节，就可以使用工厂方法模式。此外，如果一个类希望其子类定义其所创建的对象，那么工厂方法模式也会是一个好的选择。
5.1.2 对扩展性和维护性的需求
工厂方法模式也常被用于需要增强扩展性和维护性的系统中。在软件开发中，增加新的产品类型是常态，工厂方法模式可以轻松应对这种变化，因为增加新产品只需要增加相应的工厂类。
维护性方面，工厂方法模式将对象的创建逻辑封装在工厂类中，使得系统的其他部分免受创建逻辑变化的影响。即使创建逻辑发生了变化，只需要修改工厂类，而不需要修改使用工厂方法的代码，从而降低了系统的维护难度。
5.2 工厂方法模式的典型应用场景
5.2.1 系统产品的模块化
在模块化设计的系统中，不同模块可能需要创建不同种类的对象。通过工厂方法模式，可以将对象的创建封装在各个模块的工厂中，每个模块可以有其独立的工厂类，这样做的好处是模块之间的耦合度降低，更加便于模块化管理与维护。
5.2.2 对象创建过程中的依赖倒置
依赖倒置原则（Dependency Inversion Principle）提倡高层模块不应该依赖于低层模块，二者都应该依赖于抽象。工厂方法模式正是这一原则的典型实现。通过工厂方法创建的对象，客户端代码不需要知道具体类，只需知道抽象接口。这样，系统可以通过依赖抽象的方式，减少因具体类变化导致的客户端代码的修改。
为了更好地说明工厂方法模式的应用，以下是一个简单的C#示例代码，展示了工厂方法模式在创建不同类型日志记录器时的使用。
// 日志记录器接口
public interface ILogger
{
void Log(string message);
}
// 具体的日志记录器工厂
public class LoggerFactory
{
// 工厂方法
public static ILogger CreateLogger(string type)
{
switch (type)
{
case "File":
return new FileLogger();
case "Database":
return new DatabaseLogger();
default:
throw new ArgumentException("Logger type not supported.");
}
}
}
// 文件日志记录器
public class FileLogger : ILogger
{
public void Log(string message)
{
// 实现日志到文件的记录
Console.WriteLine("FileLogger: " + message);
}
}
// 数据库日志记录器
public class DatabaseLogger : ILogger
{
public void Log(string message)
{
// 实现日志到数据库的记录
Console.WriteLine("DatabaseLogger: " + message);
}
}
// 使用示例
public static void Main(string[] args)
{
ILogger logger = LoggerFactory.CreateLogger("File");
logger.Log("This is a log message.");
}
在上述代码中， ILogger 接口定义了日志记录器的抽象，而 FileLogger 和 DatabaseLogger 是具体的日志记录器实现。 LoggerFactory 类包含一个静态的工厂方法 CreateLogger ，根据输入的参数类型创建相应的日志记录器实例。这种方式使得日志记录器的具体实现对客户端代码完全透明。
工厂方法模式的使用，使得系统的架构更加灵活，便于扩展和维护，同时也满足了依赖倒置原则。通过使用工厂方法模式，我们实现了对创建过程的封装，以及对象创建逻辑的解耦。
6. 工厂方法模式对代码质量的影响
工厂方法模式是创建型设计模式之一，它提供了一种创建对象的最佳方式。在本章节中，我们将深入探讨工厂方法模式如何影响代码的可读性与扩展性，同时也会分析它对代码质量带来的潜在提升。
6.1 工厂方法模式对代码可读性的影响
6.1.1 代码结构的清晰性
工厂方法模式通过将对象的创建委托给专门的工厂类，从而实现了创建逻辑与使用逻辑的分离。这种分离使得系统的架构更加清晰，开发者可以更容易地追踪到对象是如何被创建的。
在工厂方法模式中，当我们需要创建一个对象时，不再直接通过new关键字实例化，而是通过工厂类来进行。这样做带来的好处是，如果需要了解对象创建的过程，我们只需要查看工厂类的代码，而不需要深入到各个使用该对象的类中去。代码的结构因此变得更加清晰。
// 示例代码：工厂方法模式实现
public interface IProduct
{
void Use();
}
public class ConcreteProductA : IProduct
{
public void Use()
{
Console.WriteLine("Using ProductA");
}
}
public class ConcreteProductB : IProduct
{
public void Use()
{
Console.WriteLine("Using ProductB");
}
}
public abstract class Creator
{
public abstract IProduct FactoryMethod();
}
public class ConcreteCreatorA : Creator
{
public override IProduct FactoryMethod()
{
return new ConcreteProductA();
}
}
public class ConcreteCreatorB : Creator
{
public override IProduct FactoryMethod()
{
return new ConcreteProductB();
}
}
// 使用
var creatorA = new ConcreteCreatorA();
var productA = creatorA.FactoryMethod();
productA.Use();
var creatorB = new ConcreteCreatorB();
var productB = creatorB.FactoryMethod();
productB.Use();
上述代码中， Creator 是抽象工厂类， ConcreteCreatorA 和 ConcreteCreatorB 是具体工厂类，负责生成不同类型的 Product 对象。客户端代码只需要通过工厂类来获取产品对象，而不需要关心产品是如何创建的。
6.1.2 提升代码的可维护性
当系统中引入工厂方法模式后，添加新的产品类变得相对容易。由于产品类的创建逻辑被封装在工厂类中，添加新产品的唯一条件是新产品的类必须继承自同一产品接口或类。这意味着添加新产品不需要修改现有的工厂类代码，只需新增对应的工厂类即可。
public class NewConcreteProduct : IProduct
{
public void Use()
{
Console.WriteLine("Using NewConcreteProduct");
}
}
public class NewConcreteCreator : Creator
{
public override IProduct FactoryMethod()
{
return new NewConcreteProduct();
}
}
上述代码中， NewConcreteProduct 是新添加的产品类， NewConcreteCreator 是新添加的工厂类。添加这些类后，原有的客户端代码无需任何改动即可使用新的产品类。
6.2 工厂方法模式对代码扩展性的影响
6.2.1 增强系统的灵活性
工厂方法模式使得系统在不修改现有代码的情况下可以引入新的产品类。这种设计让系统的扩展性得到了增强，因为开发者可以自由地增加新的产品类别而不影响现有的客户端代码。同时，这也减少了因修改已有代码而引入新错误的风险。
6.2.2 简化新产品的加入过程
在工厂方法模式下，新产品的加入过程通常很简单。开发者只需要遵循已有的模式，即添加一个新工厂类和一个新产品类。这种方式的加入过程既标准化又简单，使得整个系统的扩展变得简单而直接。
// 添加新产品类
public class AnotherConcreteProduct : IProduct
{
public void Use()
{
Console.WriteLine("Using AnotherConcreteProduct");
}
}
// 添加对应的工厂类
public class AnotherConcreteCreator : Creator
{
public override IProduct FactoryMethod()
{
return new AnotherConcreteProduct();
}
}
上述代码中，我们添加了 AnotherConcreteProduct 产品类和 AnotherConcreteCreator 工厂类。在不改变任何现有代码的基础上，成功地将新产品引入到系统中。
工厂方法模式的应用让代码的可读性和扩展性得到了显著提升，同时也提升了代码的整体质量。通过分离产品创建逻辑和使用逻辑，代码结构更加清晰，并且在不改变现有功能的基础上轻松扩展新功能，从而进一步提高了软件的可维护性。
7. 工厂方法与其他设计模式的组合使用
工厂方法模式作为创建型设计模式之一，其主要思想是使用一个工厂接口来创建不同类型的产品，以此来解耦产品的创建和使用。在实际的软件开发过程中，为了适应更加复杂多变的需求场景，工厂方法模式往往会与其他设计模式结合使用。本章我们将探讨工厂方法与其他设计模式的组合使用，并分析其带来的优势。
7.1 工厂方法与单例模式的结合
7.1.1 单例模式的介绍
单例模式是一种常用的软件设计模式，该模式的主要目的是确保一个类只有一个实例，并提供一个全局访问点。这种模式通常在以下情况中使用：
- 当类的唯一实例访问点非常频繁时。
- 当创建一个对象需要消耗大量资源时，而这个对象又只被使用一次，如线程池、缓存等。
单例模式实现的关键在于：
- 私有构造函数：确保外部代码无法创建该类的实例。
- 私有静态变量：存储该类的唯一实例。
- 公共静态方法：返回该实例，如果实例不存在，则创建它。
7.1.2 如何在工厂方法中实现单例
为了将单例模式与工厂方法结合起来，我们可以在工厂方法中应用单例模式，以确保工厂对象的唯一性。这样做的好处在于：
- 可以在系统初始化时就创建工厂实例，确保在后续使用过程中，无论何时访问工厂，都是同一个实例。
- 简化了资源的管理，特别是在单例工厂负责管理多个单例产品时。
具体实现时，我们可以让抽象工厂类继承自单例模式的实现类，这样所有的具体工厂都将是单例的。
public abstract class SingletonFactory<T> where T : class, new() {
private static T _instance;
protected SingletonFactory() { }
public static T Instance {
get {
if (_instance == null) {
_instance = new T();
}
return _instance;
}
}
public abstract Product Create();
}
public class ConcreteFactory : SingletonFactory<Product>, IFactory<Product> {
public override Product Create() {
return new Product();
}
}
在上述代码中， SingletonFactory<T> 是一个泛型单例工厂类，它使用懒汉式加载（Lazy Loading）来确保实例的唯一性。 ConcreteFactory 继承自 SingletonFactory<Product> ，并实现 Create 方法，用于创建产品实例。
7.2 工厂方法与策略模式的融合
7.2.1 策略模式的基本概念
策略模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响到使用算法的客户端。策略模式的目的是将算法的定义与其使用分离，从而可以灵活地切换算法。
策略模式的关键要素包括：
- 抽象策略：定义算法的接口或抽象类。
- 具体策略：实现具体的算法逻辑。
- 上下文：持有策略对象的引用，并根据策略对象执行算法。
7.2.2 策略模式与工厂方法的协同工作
将策略模式与工厂方法结合，可以使策略的选择和创建通过工厂方法来完成，从而让客户端只需与工厂交互来获取具体的策略对象。这样做的优势包括：
- 减轻了客户端的责任，它不需要了解不同策略之间的区别。
- 增加了系统的灵活性，当需要增加新的策略时，只需要增加相应的具体策略类即可，而无需修改现有的代码。
结合的实现通常涉及到两个工厂：
- 策略工厂：负责创建具体的策略对象。
- 上下文工厂：负责创建包含特定策略的上下文对象。
public interface IStrategy {
void Execute();
}
public class ConcreteStrategyA : IStrategy {
public void Execute() {
// 实现特定算法逻辑
}
}
public class StrategyFactory {
public IStrategy GetStrategy(string type) {
switch (type) {
case "A":
return new ConcreteStrategyA();
// 其他策略的创建逻辑
default:
throw new NotImplementedException();
}
}
}
public class Context {
private IStrategy _strategy;
public Context(IStrategy strategy) {
_strategy = strategy;
}
public void ExecuteStrategy() {
_strategy.Execute();
}
}
7.3 工厂方法与建造者模式的对比分析
7.3.1 建造者模式的场景和实现
建造者模式用于创建复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，而不必知道具体的构建细节。建造者模式由以下关键部分组成：
- 产品：最终要创建的复杂对象。
- 指挥者：负责安排已有模块的顺序，然后告诉构建者开始建造。
- 建造者：提供逐步构建产品的接口。
- 具体建造者：实现构建产品的接口。
建造者模式适合于：
- 创建的产品对象的算法应独立于该对象的组成部分以及它们的装配方式。
- 构建过程必须允许被构造的对象有不同的表示。
7.3.2 两种模式在解决相似问题时的比较
工厂方法和建造者模式都能创建对象，但它们的使用场景和目标有所不同。
- 工厂方法主要关注于创建对象时的类型选择，而建造者模式侧重于对象构建过程的控制和步骤化。
- 工厂方法通常用于创建简单的对象或者层次较少的对象，而建造者模式适用于创建复杂对象，尤其是那些对象的创建过程较为复杂或需要逐步构建的对象。
在实践中，可以根据对象创建的需要选择合适的模式。如果创建对象的过程很复杂，或者需要通过多步骤的方式来逐步完成对象的创建，则建造者模式可能是更好的选择。反之，如果关注点在于创建对象的类型，而且对象的创建过程并不复杂，则可以考虑使用工厂方法模式。
简介：工厂方法模式作为面向对象设计模式的一种，通过抽象工厂和具体工厂子类的实现来创建对象，遵循了“开闭原则”。在C#中，工厂方法模式可使用接口或抽象类来实现。文中提供了两个应用案例：简单工厂方法模式和多层工厂方法模式，详细介绍了如何在C#中根据不同的设计需求创建具体的产品实例。此外，还探讨了工厂方法模式适用的场景和它对代码质量的提升作用，以及与其他设计模式组合使用的可能性。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
