Dot NET设计模式—抽象工厂
1.目的
提供一个创建一系列相关或互相依赖的对象的接口，而无须指定其具体的类。
2.使用范围
在以下场合可以使用抽象工厂。
（1）一个系统要独立于其产品的创建、组合和表示时。
（2）一个系统要由多个产品系列中的一个来配置时。
（3）需要提供一个产品类库，而只想显示它们的接口，而隐藏其实现时。
3.抽象工厂的结构
抽象工厂的结构如图所示。
（1）AbstractFactory：声明一个创建抽象产品对象的操作接口。
（2）ConcreteFactory：实现创建具体产品对象的操作。
（3）AbstractProduct：为一类产品对象声明一个接口。
（4）ConcreteProduct：定义一个将被相应具体工厂创建的产品对象，以实现AbstractProduct接口。
（5）Client：仅使用AbstractFactory 和AbstractProduct类声明的接口。
4.实现示例
本节用一个简单的运输监测系统说明抽象工厂的实现，这个系统包括交通工具和车站。我们需要监测交通工具在车站之间的各种状况并希望这个系统也适用于其他场合，例如巴士系统和轻轨系统等，可以采用抽象工厂来完成创建工作。
该系统的结构如图所示。
代码结构如下。
（1）抽象工厂。
Using System;
Namespace vehicle
{
///<summary>
///VehicleSystemFactory运输系统的抽象工厂
///创建交通工具和对应的车站
///</summary>
public abstract class VehicleSystemFactory
{
public abstract Vehicle GetVehicle();
public abstract VebhicleStation GetVehicleStation();
}
}
（2）创建巴士系统的具体工厂。
using System;
namespace Vehicle
{
///<summary>
///BusSystemFactory创建巴士系统的具体工厂
///</summary>
public class BusSystemFactory：VehicleSystemFactory
{
public override Vehicle GetVehicle( )
{
return new Bus( );
}
public override VehicleStation GetVehicleStation( )
{
return new BusStation( );
}
}
}
在这个个例子中，抽象工厂是工厂方法的集合。在VehicleSystemFactory中的两个抽象的工厂方法分别创建Vehicle 和VehicleStation，具体的创建在子类中实现。
另外需要指出的是，一个系统中通常只有一个具体工厂，这个工厂可以采用单件模式来确保其惟一性。
5.使用抽象工厂的效果
抽象分离了具体的类，其效果如下。
（1）使产品系列容易交换，只要更换相应的具体工厂即可。在上例中，我们可以容
易地将管理系统在巴士和轻轨系统间切换。
（2）有利于产品的一致性，由抽象工厂创建的产品必须符合相同的接口，任何在子
类中的特殊功能都不能体现在统一的接口中。因此也就不能被客户所接受，这个限制使在不同系列的产品设计时要严格保证一致性。
应当注意，这上点是与生成器模式的最大不同，生成器创建的产品通常没有相同接口。
（3）难以支持新产品的类型。一定要理解这种产品是什么，以上例来说，有人会提出需要增加对地铁的支持，然而需要注意，增加对地铁的支持增加了产品系列这很容易，但产品未包括在交通工具和车站中。例如，需要增加维修站，为此需要在抽象工厂中增加相应的接口。抽象工厂的基类就要发生变化，而针对每个产品系列的具体工厂也都要发生变化，显然这是非常麻烦的。
提供一个创建一系列相关或互相依赖的对象的接口，而无须指定其具体的类。
2.使用范围
在以下场合可以使用抽象工厂。
（1）一个系统要独立于其产品的创建、组合和表示时。
（2）一个系统要由多个产品系列中的一个来配置时。
（3）需要提供一个产品类库，而只想显示它们的接口，而隐藏其实现时。
3.抽象工厂的结构
抽象工厂的结构如图所示。
（1）AbstractFactory：声明一个创建抽象产品对象的操作接口。
（2）ConcreteFactory：实现创建具体产品对象的操作。
（3）AbstractProduct：为一类产品对象声明一个接口。
（4）ConcreteProduct：定义一个将被相应具体工厂创建的产品对象，以实现AbstractProduct接口。
（5）Client：仅使用AbstractFactory 和AbstractProduct类声明的接口。
4.实现示例
本节用一个简单的运输监测系统说明抽象工厂的实现，这个系统包括交通工具和车站。我们需要监测交通工具在车站之间的各种状况并希望这个系统也适用于其他场合，例如巴士系统和轻轨系统等，可以采用抽象工厂来完成创建工作。
该系统的结构如图所示。
代码结构如下。
（1）抽象工厂。
Using System;
Namespace vehicle
{
///<summary>
///VehicleSystemFactory运输系统的抽象工厂
///创建交通工具和对应的车站
///</summary>
public abstract class VehicleSystemFactory
{
public abstract Vehicle GetVehicle();
public abstract VebhicleStation GetVehicleStation();
}
}
（2）创建巴士系统的具体工厂。
using System;
namespace Vehicle
{
///<summary>
///BusSystemFactory创建巴士系统的具体工厂
///</summary>
public class BusSystemFactory：VehicleSystemFactory
{
public override Vehicle GetVehicle( )
{
return new Bus( );
}
public override VehicleStation GetVehicleStation( )
{
return new BusStation( );
}
}
}
在这个个例子中，抽象工厂是工厂方法的集合。在VehicleSystemFactory中的两个抽象的工厂方法分别创建Vehicle 和VehicleStation，具体的创建在子类中实现。
另外需要指出的是，一个系统中通常只有一个具体工厂，这个工厂可以采用单件模式来确保其惟一性。
5.使用抽象工厂的效果
抽象分离了具体的类，其效果如下。
（1）使产品系列容易交换，只要更换相应的具体工厂即可。在上例中，我们可以容
易地将管理系统在巴士和轻轨系统间切换。
（2）有利于产品的一致性，由抽象工厂创建的产品必须符合相同的接口，任何在子
类中的特殊功能都不能体现在统一的接口中。因此也就不能被客户所接受，这个限制使在不同系列的产品设计时要严格保证一致性。
应当注意，这上点是与生成器模式的最大不同，生成器创建的产品通常没有相同接口。
（3）难以支持新产品的类型。一定要理解这种产品是什么，以上例来说，有人会提出需要增加对地铁的支持，然而需要注意，增加对地铁的支持增加了产品系列这很容易，但产品未包括在交通工具和车站中。例如，需要增加维修站，为此需要在抽象工厂中增加相应的接口。抽象工厂的基类就要发生变化，而针对每个产品系列的具体工厂也都要发生变化，显然这是非常麻烦的。
