1、抽象工厂简介
在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。
- 如何应对这种变化？
- 如何绕过常规的对象的创建方法（new）？
- 如何来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？
然而抽象工厂便可以很好地解决这个问题！
2、意图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
3、适用性
- 一个系统要独立与它的产品创建、组合和表示时
- 一个系统要由多个产品系列中的一个来配置时
- 当你要强调一系列相关的产品对象的设计以便进行联合使用时
- 当你提供一个产品类库，而只想显示它们的接口而不是实现时
4、结构图
5、应用实例
注：此案例，借鉴网络资料；比较易于学习，所以自己练习了下，在这里也给大家分享了！
中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。
员工工资 = 基本工资 + 奖金 - 个人所得税 ； 为了简化系统，这里定义员工基本工资：4000
中国企业奖金和个人所得税的计算规则是：
奖金 = 基本工资 * 10%
个人所得税 =（基本工资 + 奖金） * 40%
为此我们要构造一个系统，满足中国企业的需要：(名称Softo)
/// <summary>
/// 公用变量基本工资
/// </summary>
public class Constant
{
public static double base_salary = 4000;
}
/// <summary>
/// 计算中国个人奖金
/// </summary>
public class ChinaBonus
{
public double Calculate()
{
return Constant.base_salary * 0.1;
}
}
/// <summary>
/// 计算个人所得税
/// </summary>
public class ChinaTax
{
public double Calculate()
{
return (Constant.base_salary + Constant.base_salary * 0.1) * 0.4;
}
}
客户端调用：
static void Main(string[] args)
{
double bonusValue_China = new ChinaBonus().Calculate();
double taxValue_China = new ChinaTax().Calculate();
double salary_China = 4000 + bonusValue_China - taxValue_China;
Console.WriteLine("China Salary is：" + salary_China);
}
运行结果：
以上满足了中国企业需求，但为了拓展国际市场，需求发生变更；我们要把该系统移植给美国公司使用，员工工资计算规则不变；但是奖金和个人所得税不同于中国，其规则如下：
奖金 = 基本工资 * 15%
个人所得税 = 基本工资 * 5% + 奖金 * 25%
根据现有系统，我们只需要做如下更改：
/// <summary>
/// 公用变量基本工资
/// </summary>
public class Constant
{
public static double base_salary = 4000;
}
/// <summary>
/// 计算美国个人奖金
/// </summary>
public class AmericanBonus
{
public double Calculate()
{
return Constant.base_salary * 0.1;
}
}
/// <summary>
/// 计算美国个人所得税
/// </summary>
public class AmericanTax
{
public double Calculate()
{
return (Constant.base_salary + Constant.base_salary * 0.1) * 0.4;
}
}
客户端调用：
static void Main(string[] args)
{
double bonusValue_American = new AmericanBonus().Calculate();
double taxValue_American = new AmericanTax().Calculate();
double salary_American = 4000 + bonusValue_American - taxValue_American;
Console.WriteLine("American Salary is：" + salary_American);
Console.ReadLine();
}
运行结果：
为了以后业务拓展，我们打算把Softo整合为通用系统：
比较以上两个系统，业务规则类发生了变化，客户端调用发生了变化，如果要做通用的就必须保留所有的业务规则模型，在中国与美国之间切换时，只需要修改客户端调用即可。
但是，一个维护性良好的系统应该遵循“开闭原则”。即：封闭对原来代码的修改，开放对原来代码的扩展 （如类的继承，接口的实现）。我们发现不论是中国企业还是美国企业，他们的业务运规则都采用同样的计算接口，于是修改如下：
class Program
{
static void Main(string[] args)
{
IBonus bonus = new ChinaBonus();
double bonusValue_China = bonus.Calculate();
ITax tax = new ChinaTax();
double taxValue_China = tax.Calculate();
double salary_China = 4000 + bonusValue_China - taxValue_China;
Console.WriteLine("China Salary is：" + salary_China);
Console.ReadLine();
}
}
/// <summary>
/// 公用变量基本工资
/// </summary>
public class Constant
{
public static double base_salary = 4000;
}
public interface IBonus
{
double Calculate();
}
public interface ITax
{
double Calculate();
}
/// <summary>
/// 计算中国个人奖金
/// </summary>
public class ChinaBonus : IBonus
{
public double Calculate()
{
return Constant.base_salary * 0.1;
}
}
/// <summary>
/// 计算个人所得税
/// </summary>
public class ChinaTax : ITax
{
public double Calculate()
{
return (Constant.base_salary + Constant.base_salary * 0.1) * 0.4;
}
}
/// <summary>
/// 计算美国个人奖金
/// </summary>
public class AmericanBonus : IBonus
{
public double Calculate()
{
return Constant.base_salary * 0.1;
}
}
/// <summary>
/// 计算美国个人所得税
/// </summary>
public class AmericanTax : ITax
{
public double Calculate()
{
return (Constant.base_salary + Constant.base_salary * 0.1) * 0.4;
}
}
运行结果：
然而，上面增加的接口几乎没有解决任何问题，因为当系统的客户在美国和中国企业间切换时，客户端仍然需要修改；
为此增加一个工具类Factory:
public class Factory
{
public IBonus CreateBonus()
{
return new ChinaBonus();
}
public ITax CreateTax()
{
return new ChinaTax();
}
}
客户端调用：
static void Main(string[] args)
{
IBonus bonus = new Factory().CreateBonus();
double bonusValue = bonus.Calculate();
ITax tax = new Factory().CreateTax();
double taxValue = tax.Calculate();
double salary = 4000 + bonusValue - taxValue;
Console.WriteLine(" Salary is：" + salary);
Console.ReadLine();
}
运行结果：
此时，如果我们把该系统移植到美国，只需修改Factory工具类，把ChinaBonus替换为AmericanBonus；ChinaTax替换为AmericanTax即可；其实这也有一个副作用，新建了一个Factory类，并且把修改点转移到该类中，并没有解决根本问题；而且这个工具类可能是专属于美国企业或者中国企业的，名称叫：AmericanFactory,ChineseFactory更合适。那我们该解决这个问题？
此时才引入重点，添加抽象工厂方法：
增加一个静态方法，该方法根据一个配置文件动态地判断应该实例化哪个工厂类；
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="factoryName" value="ChinaFactory"></add>
</appSettings>
</configuration>
/// <summary>
/// AbstractFactory
/// </summary>
public abstract class AbstractFactory
{
public static AbstractFactory GetInstance()
{
string factoryName = ConfigurationManager.AppSettings["factoryName"];
AbstractFactory instance;
switch (factoryName)
{
case "ChinaFactory":
instance = new ChinaFactory(); break;
case "AmericanFactory":
instance = new AmericanFactory(); break;
default:
instance = null; break;
}
return instance;
}
public abstract IBonus CreateBonus();
public abstract ITax CreateTax();
}
public class ChinaFactory : AbstractFactory
{
public override IBonus CreateBonus()
{
return new ChinaBonus();
}
public override ITax CreateTax()
{
return new ChinaTax();
}
}
public class AmericanFactory : AbstractFactory
{
public override IBonus CreateBonus()
{
return new AmericanBonus();
}
public override ITax CreateTax()
{
return new AmericanTax();
}
}
客户端调用：
static void Main(string[] args)
{
AbstractFactory instanceFac = AbstractFactory.GetInstance();
double bonusValue = instanceFac.CreateBonus().Calculate();
double taxValue = instanceFac.CreateTax().Calculate();
double salary = 4000 + bonusValue - taxValue;
Console.WriteLine(" Salary is：" + salary);
Console.ReadLine();
}
运行结果：
此时当系统在美国企业和中国企业之间切换时，我们只需要修改配置
改为AmericanFactory即可。
相信你看到这里也会赶脚到抽象工厂的强大吧！其实以上解决方案并不是最完美的，不知是否满过你的锐眼？
抽象工厂类中采用了分支判断，一旦业务更加广泛，不只是美国，有拓展至德国，此时我们不但要增加新的业务规则类：德国Tax、德国Bonus分别实现ITax和IBonus接口，新增德国Factory继承自AbstractFactory，而且还要添加AbstractFactory中的case分支，这依然不能满足OCP！至于该如何解决该问题，且看下节分析！
6、总结
- 最后使用抽象工厂模式后，我们会发现客户端完全依赖于抽象类，它不必去理解中国和美国企业具体的业务规则如何实现；面对的只是业务规则接口IBonus和ITax；从而把业务规则与客户端调用完全分离，从而降低耦合度；
- 完完全全地理解抽象工厂模式的意义非常重大，可以说对它的理解是你对OOP理解上升到一个新的里程碑的重要标志。学会了用抽象工厂模式编写框架类，你将理解OOP的精华：面向接口编程。
注：虽然案例是搜集的资料，但通过自己的整理与测试！希望博友能够尊重我的劳动成果，大家互相学习、共同进步！