抽象工厂模式和简单工厂模式

[wjb_yd]

小弟初学设计模式，对这个抽象工厂模式不是很理解。
简单工厂我明白
{/code}
{
Car *p = new BaoMa;
}
{/code}
如果不用简单工厂模式，如果BaoMa要换成AoDi，那么如果创建了100个车子，就需要修改100处源代码。
如果改成这样
{/code}
{
CarFactory* f = new BaoMaFactory;
Car *p = f.create();
}
{/code}
这样如果BaoMa要换成AoDi，只要将BaoMaFactory换成AodiFactory就行。

但是抽象工厂模式的原理我明白，就是想象不出来再实际开发中解决什么问题，哪位朋友能帮忙举一个通俗易懂的抽象工厂模式使用的例子吗？

多谢！

[donkey301]

http://terrylee.cnblogs.com/archive/2005/12/13/295965.html
我的理解是abstract factory的实现一般都和factory method是放在一起的
也就是

class AbstractFactory
{
   virtual FactoryMethod1();
   virtual FactoryMethod2();
}
class ConcreteFactory : public AbstractFactory
{
   virtual FactoryMethod1();
   virtual FactoryMethod2();

}

[carpe__diem]

Abstract 就是工厂的工厂。
如果你有太多的工厂，那就像类一样要改动一个工厂就要改动所有使用它的地方，
所以用抽象工厂来统一工厂的调用。

[云瑀]

你可以理解成这样子
家具工厂有一个生产的方法
然后食品工厂也有一个生产的方法
车子工厂也有一个生产的方法
这三种工厂是不同的工厂
但是它门都是工厂

[jpphy]

对于客户端而言，无论是工厂方法模式还是抽象工厂模式：

1、共同点：都是先生成工厂类对象的实例，然后再通过工厂类对象的实例生成产品类对象的实例。

2、不同点：在生成工厂类对象的实例时候，选择工厂类的策略是不同的，工厂方法模式是依据需要的单个产品的特征，而抽象工厂模式则是依据多个产品的共同特征。

或者可以理解为：是相互联系在一起的工厂的工厂，其中所谓的相互联系，可参照上述不同点中的“多个产品的共同特征”。

[babytao163]

不同点：在生成工厂类对象的实例时候，选择工厂类的策略是不同的，工厂方法模式是依据需要的单个产品的特征，而抽象工厂模式则是依据多个产品的共同特征

[jpphy]

补充：

抽象工厂或者可以理解为：是相互联系在一起的工厂的工厂。其中所谓的相互联系，可参照上述不同点中的“多个产品的共同特征”。

[donkey301]

楼上两位说的不错，我以前的理解还是不够深刻。

[q107770540]

LZ可以去参考一下petshop源码

[JerryNing]

系列产品的话选择抽象工厂。比如肯德基和麦当劳都是工厂，都有一系列产品（汉堡，可乐，薯条），这样的情况选择抽象工厂。
如果只有一种产品，多个厂家都可以生产，比如宝马汽车和奥迪汽车，这样的情况选择工厂模式。

如果一个工厂可以生产很多种产品，这样的情况应该选择简单工厂模式。

[arkhan]

对于抽象工厂,我举个生活中的例子方便你的理解。
比如说一家品牌笔记本供应商A，他要找一家代工的OEM厂商B帮他生产笔记本，由A提供笔记本的工艺规格等，比如说cpu,硬盘等等的品牌和规格（这就是抽象工厂的定义）。之后，可能A又找到另一家OEM厂商C，C的报价比B便宜，这个时候由于使用了抽象工厂，A不需要改动任何规格，直接就可以把给B的单子转给C做。
A制定的规格就是抽象工厂，B和C就是该抽象工厂的不同实现（实体工厂），而B和C的产品就是抽象产品的不同实现。
由于使用了抽象工厂，因为工艺不变（接口一致），所以随时随地可以更换OEM厂商（实体工厂）而不需要重新修改跟接口相关的代码。抽象工厂和实体工厂的mapping可以用config文件甚至IOC框架来动态配置

[运算符科技]

为了不违背DIP原则（The Dependency Inversion Principle，依赖倒置原则)。

通俗说，Client使用类A，B，C；其中B,C从A派生。。那么在类Client中，可能出现类似这样的代码：
A* pA = new B();
A* pA = new C();

这导致类Client直接依赖A，B，C，其中BC都为具体类。违反了依赖倒置原则。

如果使用Abstract Factory（抽象工厂），那么Client类只需要知道抽象接口AbstractInterface，该接口类提供了两个函数CreateB，CreateC。具体类ConcreteInterface从AbstractInterface派生，实现了两个抽象函数：
A* CreateB()
{
return new B();
}
A* CreateC()
{
return new C();
}

如此修改，Client类就只依赖接口类AbstractInterface和类A了，与具体的类B,C解耦。

[Dolphin_001]

推荐你看下深处浅处设计模式，很通俗易懂。

[cxyOOOO]

[Quote=引用 11 楼 alicehyxx 的回复:]

为了不违背DIP原则（The Dependency Inversion Principle，依赖倒置原则)。

通俗说，Client使用类A，B，C；其中B,C从A派生。。那么在类Client中，可能出现类似这样的代码：
A* pA = new B();
A* pA = new C();

这导致类Client直接依赖A，B，C，其中BC都为具体类。违反了依赖倒置原则。

如果使……
[/Quote]



说的不完全对。如果为了解决client和类B，C的耦合，可以使用2个工厂分别生成B和C；也可以使用1个工厂实例并分别传递类型参数。(B和C同派生自A)


抽象工厂面对的问题如下：
存在基类A，以及A的派生类A1，A2，...；同时存在B的派生类B1，B2，...
在一个context中要同时使用：
A* = new A1;
B* = new B1;
导致A1和B1耦合，如果context发生变化要求使用A1和B2（或者A2和B1，或者...），如何解决这个问题？
gof书中抽象工厂的意图，说的比较清楚。

[cxyOOOO]

A和B不需要具备共同的父类。

[ITTA2010]

其实都一样 抽象工厂多了一层而已