关闭

抽象工厂模式(Abstract Factory)

294人阅读 评论(0) 收藏 举报

概述

在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时由于需求的变化,往往存在着更多系列对象的创建工作。如何应对这种变化?如何绕过常规的对象的创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?这就是我们要说的抽象工厂模式。

提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类

逻辑模型:


物理模型:


抽象工厂之新解

虚拟案例

中国企业需要一项简单的财务计算:每月月底,财务人员要计算员工的工资。

员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是一个放之四海皆准的运算法则。

为了简化系统,我们假设员工基本工资总是4000美金。

中国企业奖金和个人所得税的计算规则是:

         奖金 = 基本工资(4000) * 10%

         个人所得税 = (基本工资 + 奖金) * 40%

我们现在要为此构建一个软件系统(代号叫Softo),满足中国企业的需求。

案例分析

奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)

工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。

工资的计算作为业务规则的前端(或者客户端Client)将提供给最终使用该系统的用户(财务人员)使用。

通用的系统模式:

抽象工厂类的代码如下:

 1using System;
 2 using System.Reflection;
 3 
 4 namespace AbstractFactory
 5 {
 6     /**//// <summary>
 7     /// AbstractFactory类
 8     /// </summary>

 9     public abstract class AbstractFactory
10    {
11        public static AbstractFactory GetInstance()
12        {
13            string factoryName = Constant.STR_FACTORYNAME.ToString();
14
15            AbstractFactory instance;
16
17            if(factoryName == "ChineseFactory")
18                instance = new ChineseFactory();
19           else if(factoryName == "AmericanFactory")
20                instance = new AmericanFactory();
21            else
22                instance = null;
23
24            return instance;
25        }

26
27        public abstract Tax CreateTax();
28
29        public abstract Bonus CreateBonus();
30    }

31}
 

 

客户端代码:

 1using System;
 2
 3 namespace FactorySalary
 4 {
 5   /**//// <summary>
 6    /// 客户端程序调用
 7    /// </summary>

 8    public class Calculator 
 9   {
10        public static void Main(string[] args) 
11       {
12           Bonus bonus = new Factory().CreateBonus();
13           double bonusValue  = bonus.Calculate();
14  
15            Tax tax = new Factory().CreateTax();
16           double taxValue = tax.Calculate();
17    
18            double salary = 4000 + bonusValue - taxValue; 
19
20            Console.WriteLine("Chinaese Salary is:" + salary);
21            Console.ReadLine();
22       }

23   }

24}

25

配置文件:
1<?xml version="1.0" encoding="utf-8" ?>
2<configuration>
3    <appSettings>
4        <add key="factoryName" value="AmericanFactory"></add>
5    </appSettings>
6</configuration>

 

采用上面的解决方案,当系统在美国企业和中国企业之间切换时,我们需要做什么移植工作?

 

答案是: 我们仅仅需要修改配置文件,将factoryName的值改为American

修改配置文件的工作很简单,只要写一篇幅配置文档说明书提供给移植该系统的团队(比如Hippo公司) 就可以方便地切换使该系统运行在美国或中国企业。

最后的修正(不是最终方案)

前面的解决方案几乎很完美,但是还有一点瑕疵,瑕疵虽小,但可能是致命的。

考虑一下,现在日本NEC公司决定购买该系统,NEC公司的工资的运算规则遵守的是日本的法律。如果采用上面的系统构架,这个移植我们要做哪些工作呢?

1.      增加新的业务规则类JapaneseTax,JapaneseBonus分别实现TaxBonus接口。

2.      修改AbstractFactorygetInstance方法,增加else if(factoryName.equals("Japanese")){....

注意: 系统中增加业务规则类不是模式所能解决的,无论采用什么设计模式,JapaneseTax,JapaneseBonus总是少不了的。(即增加了新系列产品)

我们真正不能接受的是:我们仍然修要修改系统中原来的类(AbstractFactory)。前面提到过该系统的移植工作,我们可能转包给一个叫Hippo的软件公司。 为了维护版权,未将该系统的源码提供给Hippo公司,那么Hippo公司根本无法修改AbstractFactory,所以系统移植其实无从谈起,或者说系统移植总要开发人员亲自参与。

解决方案是将抽象工厂类中的条件判断语句,用.NET中发射机制代替,修改如下:

 

 1using System;
 2 using System.Reflection;
 3 
 4 namespace AbstractFactory
 5 {
 6     /**//// <summary>
 7     /// AbstractFactory类
 8     /// </summary>

 9     public abstract class AbstractFactory
10   {
11        public static AbstractFactory GetInstance()
12        {
13            string factoryName = Constant.STR_FACTORYNAME.ToString();
14
15            AbstractFactory instance;
16
17            if(factoryName != "")
18                instance = (AbstractFactory)Assembly.Load(factoryName).CreateInstance(factoryName);
19            else
20                instance = null;
21
22            return instance;
23        }

24
25        public abstract Tax CreateTax();
26
27        public abstract Bonus CreateBonus();
28    }

29}

30

 这样,在我们编写的代码中就不会出现ChineseAmericanJapanese等这样的字眼了

小结

最后那幅图是最终版的系统模型图。我们发现作为客户端角色的Calculator仅仅依赖抽象类, 它不必去理解中国和美国企业具体的业务规则如何实现,Calculator面对的仅仅是业务规则接口TaxBonus

 

Softo系统的实际开发的分工可能是一个团队专门做业务规则,另一个团队专门做前端的业务规则组装。 抽象工厂模式有助于这样的团队的分工: 两个团队通讯的约定是业务接口,由抽象工厂作为纽带粘合业务规则和前段调用,大大降低了模块间的耦合性,提高了团队开发效率。

完完全全地理解抽象工厂模式的意义非常重大,可以说对它的理解是你对OOP理解上升到一个新的里程碑的重要标志。 学会了用抽象工厂模式编写框架类,你将理解OOP的精华:面向接口编程.

应对“新对象”

抽象工厂模式主要在于应对“新系列”的需求变化。其缺点在于难于应付“新对象”的需求变动。如果在开发中出现了新对象,该如何去解决呢?这个问题并没有一个好的答案,下面我们看一下李建忠老师的回答:

GOF《设计模式》中提出过一种解决方法,即给创建对象的操作增加参数,但这种做法并不能令人满意。事实上,对于新系列加新对象,就我所知,目前还没有完美的做法,只有一些演化的思路,这种变化实在是太剧烈了,因为系统对于新的对象是完全陌生的。

实现要点

        抽象工厂将产品对象的创建延迟到它的具体工厂的子类。

        如果没有应对“多系列对象创建”的需求变化,则没有必要使用抽象工厂模式,这时候使用简单的静态工厂完全可以。

        系列对象指的是这些对象之间有相互依赖、或作用的关系,例如游戏开发场景中的“道路”与“房屋”的依赖,“道路”与“地道”的依赖。

        抽象工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化。

         通常在运行时刻创建一个具体工厂类的实例,这一具体工厂的创建具有特定实现的产品对象,为创建不同的产品对象,客户应使用不同的具体工厂。

        把工厂作为单件,一个应用中一般每个产品系列只需一个具体工厂的实例,因此,工厂通常最好实现为一个单件模式。

l         创建产品,抽象工厂仅声明一个创建产品的接口,真正创建产品是由具体产品类创建的,最通常的一个办法是为每一个产品定义一个工厂方法,一个具体的工厂将为每个产品重定义该工厂方法以指定产品,虽然这样的实现很简单,但它确要求每个产品系列都要有一个新的具体工厂子类,即使这些产品系列的差别很小。

优点

      分离了具体的类。抽象工厂模式帮助你控制一个应用创建的对象的类,因为一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离,客户通过他们的抽象接口操纵实例,产品的类名也在具体工厂的实现中被分离,它们不出现在客户代码中。

        它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置,这是因为一个抽象工厂创建了一个完整的产品系列,所以整个产品系列会立刻改变。

        它有利于产品的一致性。当一个系列的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要,而抽象工厂很容易实现这一点。

缺点

        难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合,支持新种类的产品就需要扩展该工厂接口,这将涉及抽象工厂类及其所有子类的改变。

适用性

在以下情况下应当考虑使用抽象工厂模式:

         一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节,这对于所有形态的工厂模式都是重要的。

         这个系统有多于一个的产品族,而系统只消费其中某一产品族。

        同属于同一个产品族的产品是在一起使用的,这一约束必须在系统的设计中体现出来。

        系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于实现。

应用场景

         支持多种观感标准的用户界面工具箱(Kit)。

        游戏开发中的多风格系列场景,比如道路,房屋,管道等。

        ……

总结

总之,抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口,运用抽象工厂模式的关键点在于应对“多系列对象创建”的需求变化。一句话,学会了抽象工厂模式,你将理解OOP的精华:面向接口编程。

 原文来自:TerryLee的技术专栏

 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:11877次
    • 积分:243
    • 等级:
    • 排名:千里之外
    • 原创:10篇
    • 转载:5篇
    • 译文:0篇
    • 评论:2条
    文章分类