C#中23个经典设计模式（1）——ABSTRACT FACTORY(抽象工厂)

意图

           在《Design Patterns》一书中，ABSTRACT FACTORY(图省事以下用AF代替了)模式是第一个被介绍的模式，个人以为AF模式也是最容易理解的模式之一。 
          《Design Patterns》中，对AF模式的描述是这样的：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。用通俗一点的话说：有一个对象，它可以创建一堆一系列的其他对象，每个系列的对象是从一个基类派生的。个人觉得，这些所谓的意图理解不理解问题都不是很大，知道什么时候应该使用什么模式就够了，这就叫“只能意会，不能言传”。

别名

           Kit ，这个别名用途不大，现在基本都是用AF称呼这个模式，很少有使用Kit的。

实现 

           有一些类表示一个“产品”的“同功能，不同类型的部件”，我们的应用中要使用这些类，由于OOP的多态性为了方便使用，基本是要靠派生的：

 1//一系列的“喇叭”，估计这个说吧，最后一个是外星语的
 2//它们都从Speaker派生，这是废话
 3public class Speaker {
 4    virtual public string SayHi() {
 5        return "Hello";
 6    }
 7}
 8
 9public class ChineseSpeaker : Speaker {
10    public override string SayHi() {
11        return "你好";
12    }
13}
14
15public class FjidjSpeaker : Speaker {
16    public override string SayHi() {
17        return "%F&*#";    
18}
19}

            光有这样一些类虽然也可以使用AF模式，但是这样似乎没有什么意义，AF模式经常要制作几个系列的对象，那几个系列的对象还要有逻辑上的关系，否则不但不会起到应有的作用还能使程序变得更加恶心。再定义一组“部件”：

 1//构造一块屏幕，代码没什么意思
 2public class Screen {
 3    virtual public string Display() {
 4        return "This is Screen";
 5    }
 6}
 7
 8public class ChineseScreen : Screen {
 9    public override string Display() {
10        return "这是屏幕";
11    }
12}
13
14public class FfdhkScreen : Screen {
15    public override string Display() {
16        return "SF&*&*#%";
17    }
18}

        现在有了两个“部件”了，一个喇叭，一个屏幕。我们需要把这个东西组成一个“产品”，考虑以下事实：每一中产品中的喇叭和屏幕必须是对应的（其实也可以混合，不过这样......)，假设这个产品叫做"xToy“，那就应该有一个给我这种英文盲使用的"ChineseXtoy"和给外星人使用的"DFxToy”，标准的是英文版的"xToy"。

//一个更加无聊的类，甚至唯一的Play()方法都毫无意义（还是错误的）
//但是，能够说明问题就好了
public class xToy {
    public xToy(Speaker sp, Screen scr) {
        _speaker = sp;
        _screen = scr;
    }   

    public void Play() {
        _speaker.SayHi();
        _screen.Display();
    }

    private Speaker _speaker;
    private Screen _screen;
}

   由于OOP的多态性，我们不需要为中文版和外星版创建子类了，只要改变传入的Speaker对象和Scrren对象就好。看起来像这样：

//标准版
xToy std = new xToy(new Speaker(), new Screen() );

//中文版
xToy c = new xToy(new ChineseSpeaker(), new Chinese());

//外星版
xToy f = new xToy(new FjidjSpeaker(), new FfjhkScreen());

//同时我们可以创建一个“疯狂”版
xToy cray = new xToy(new ChineseSpeaker(), new FfjhkScreen());

        这样实现，达到了预期的效果，但是也给创建“疯狂版”留下了捷径。要解决疯狂版的问题，我们可以加入验证过程，保证传入的喇叭和屏幕是对应系列的，或者可以派生xToy类，使用新的构造函数。这两种办法都增加了不少工作，尤其前者，如何判断实现无关的两个对象逻辑上十分相关？或者给那两个对象建立关系？
        更麻烦的是，如果以后这个玩具增加更多的部分，那么就会有一个非常恐怖的构造函数了

xToy ex = new xToy(new Speaker(), new Screen(), new Keybroad(), new Handle(), new OtherThing());

        解决的办法之还是可以派生产品的“子类”，让子类完成创建这些新加入的部件的工作。 或者，我们在这里就可以使用AF模式了，首先创造一个新的基类，用于创建标准的Speaker和Screen，然后派生它，用于创建其他“非标准”的部件

public class Fac {
    virtual public Speaker CreateSpeaker() {
        return new Speaker();
    }

    virtual public Screen CreateScreen() [
        return new Screen();
    }
}

public class ChFac() : Fac {
    public override Speaker CreateSpeaker() {
        return new ChineseSpeak();
    }

    public override Screen CreateScreen() {
        return new ChineseScreen();
    }
}

        最后，xToy类的构造函数也是要修改的,接受一个Fac对象，并调用Fac的两个方法创建“产品”

public xToy(Fac fac) {
    _speaker = fac.CreateSpeaker();
    _screen = fac.CreateScreen();
}

　现在要构造不同的产品，只要传入不同的“工厂”就可以了

xToy std = new xToy(new Fac());

xToy c = new xToy(new ChFac());

     实际应用中，Fac类应实现为一个抽象类，本身不进行任何工作，这也是AF模式得名的原因。

C#中的情况     
        在C#中，由于有了接口和抽象类两种用于继承的体制，所以AF模式的实现就分为抽象类实现和接口实现两种方式，我个人建议，实现AF模式，一定不要使用接口实现的方式，一个IFactory接口是让人非常困惑的，AF模式的本质是类"is a"工厂”而不是"has a"工厂。
        虽然C#中有完善的垃圾回收机制，但是像上面这样每次构造“产品”都要先构造“工厂”是无法令人接受的，把“工厂”实现为SINGLETON模式是非常好的，或者把“工厂”改变为静态类也是非常好的。

缺陷
        要添加制造不同“产品”的“工厂”很容易，只要派生“部件”类和“工厂”类就可以了。要改变不同组合更容易，只要派生“工厂”类就可以了。但是，如果要给“产品”增加一个新的“部件”就非常痛苦了，要改变“产品”类（不论是否使用AF模式，这都是必须的），要添加一个新的“部件”类（这也是必须的），要改变所有的“工厂”类（包括所有派生类），这样的话整个实现体系都要全部修改，麻烦是很多的，好在所有使用“产品”的应用不需要修改。
        对于上面的问题，还有一种解决办法，就是派生“产品”类来表示“添加了新的部件的产品”，同时派生“工厂”类和“部件”类，这样的一个很大的问题就是，新的“产品”失去了通用的“工厂”接口，必须为其传入新的“工厂”，否则编译时就会出错。同样，所有使用“产品”的应用不需要修改（使用新“产品”的应用应该使用新的接口）。

相关模式
        SINGLETON：AF模式基本使用SINGLETON模式构建。
        FACTORY METHOD: AF模式与其非常相似，但是抽象级别不同，简单说FACTORY METHOD就是使用接口实现的，是"has a“工厂的本质。