设计模式-Abstract Factory模式

        还是一个创造型模式,可以简单的认为,创造型模式就是对用户使用new的一个封装,封装作为面向对象一个重要的特性,它绝对不是一对大括号那么简单,他重要的是封装变化点.如果没有变化,那就别封装吧,直接让用户new吧,这样效率是最高的,但因为会有变化,所以才会有面向对象和设计模式.抽象工厂是应对这样的一系列变化的,比如我们最初需要一个road类,用以表现我们游戏项目的道路,那么,我们可以简单的这样表示:

 

Road road = new Road();

但是后来需求变了,我需要提供另一种道路模型,按上面的实现方式,我们需要改动客户代码,比如

 

WaterRoad = new WaterRoad();

这时候,我们可以简单的封装这个变化点,提供一个接口函数(也就是工厂)来创造类,而客户端每次不直接new类了,而是从这个工厂里申请类.这里有个前提就是如果有变化,我们最不希望修改的是哪部分,有变化肯定会造成一部分代码的修改,在这里,我们不希望修改的是客户端的代码,举个例子,客户端有复杂的游戏逻辑,比如

 

class RoadFactory
...{
    public static Road CreateRoad()
    ...{
        return new Road();
    }
}


//client
Road road = RoadFactory.CreateRoad();

    //利用road实现的复杂游戏逻辑

我不希望改动的是这部分的代码,而在C++中,应对变化的方法是"实则需之",把几个要变化的东西虚之,利用多态,在运行时决定它的类型.
有个有意思的例子,陪D逛街,D打算吃鸡腿和薯条,我可以来到麦当劳或者肯德基,对他们说给我个鸡腿和薯条就好了.在这里,麦当劳和肯德基就是一个工厂,而我是客户.我不需要对我的行为做很大修改,只要来到麦当劳给钱,拿食品,然后和D分享就好了,我换肯德基也是这样,以后有新的店子,只要他提供鸡腿和薯条,我都可以这么做.所以抽象工厂设计模式很适应我选择在不同店子买鸡腿和薯条的变化.抽象工厂不能处理的是,我需求的产品数量应该固定,或者说应该对工厂透明,即我只能要工厂能提供的产品,如果D今天要薯条或鸡腿,明天要吃中国面条,那估计麦当劳和肯德基这个工厂必须做大修改了.
通过看《COM技术内幕》,对面向对象也有了进一步的认识,应该保证接口稳定,客户和接口通信,在C++中,我们应该把容易变化的变成抽象类,客户使用抽象类,由于可以使用不同的类来实现抽象类的接口,所以客户可以在不改变的情况下,也拥有了抽象类的这种变化.抽象类的决定是在运行时.这也体现了中国古代的中庸哲学,把容易变化的东西留到最后再决定,保证其他事物的正常运作.抽象工厂需要抽象的是两种类型,一种是抽象工厂,把它抽象了,就可以在运行时提供不同的工厂.还有就是产品,在运行时就能更换不同的产品.还有一个需要注意的地方是,之所以还用了抽象工厂,是因为工厂类的产品有一定的依赖关系,换句话说,D喜欢麦当劳的薯条配麦当劳的可乐,不喜欢麦当劳的薯条配肯德基的可乐,这也是抽象工厂意图--"提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。"中"相关或相互依赖"的意义.所以没有模式是万能的,每个模式都有它的适应范围.