工厂方法模式和抽象工厂模式区别

更多精彩请到 http://www.139ya.com

转自: http://www.javaeye.com/topic/18648?page=1

A: -----------------------------------------

Factory Method:
Define an interface for create an object,but let subclass decide which class to instantiate.Factory Method lets a class defer instantiation to the subclasses.

Abstract Factory:
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.


我的疑问是：
1
工厂方法模式能不能看成是一种极端情况的抽象工厂模式，而抽象工厂模式可以看成是工厂方法模式的一种推广？


因为根据定义，工厂方法模式是用来创建一个产品的等级结构的，而抽象工厂模式是用来创建多个产品的等级结构的。

那么假如目前使用工厂方法模式创建不同类型的苹果，示例代码如下：
public interface Factory
{
Apple createApple();
}

public class ConcreteFactory1 implements Factory
{
public Apple createApple()
{
return new RedApple();
}

}

public class ConcreteFactory2 implements Factory
{
public Apple createApple()
{
return new GreenApple();
}
}

上面的代码是使用工厂方法模式。那么现在假如现在我需要创建葡萄，因此需要增加创建葡萄的方法。代码如下：
public interface Factory
{
Apple createApple();
Grape createGrape();
}

public class ConcreteFactory1 implements Factory
{
public Apple createApple()
{
return new RedApple();
}

public Grape createGrape()
{
return new RedGrape();
}

}

public class ConcreteFactory2 implements Factory
{
public Apple createApple()
{
return new GreenApple();
}

public Grape createGrape()
{
return new GreenGrape();
}

}

增加创建葡萄的方法以后，就把一个工厂方法模式变成了一个抽象工厂模式，同样的道理，假如我现在去掉创建葡萄的方法以后，我就把一个抽象工厂模式变成了工厂方法模式。因此可不可以认为这两者之间在不同情况下可以相互转换？

2
“工厂方法模式是采用inheritence，而抽象工厂模式是采用composition。”但是我看不出这就是它们的区别。我同样可以把工厂方法模式中的工厂交给客户端，从而为客户端产生一个产品的不同类型。这样客户端直接依赖于一个工厂，难道这里不也是composition?

3
“工厂方法模式通常和模板方法模式一起结合使用。”但是我仍然看不出来这也是它们的区别。我同样可以把一个抽象工厂模式结合模板方法模式使用。

期待达人解惑！

B:---------------------------------------------------------

工厂方法创建一般只有一个方法，创建一种产品。
抽象工厂一般有多个方法，创建一系列产品。


目的不一样
工厂方法创建 "一种" 产品，他的着重点在于"怎么创建"，也就是说如果你开发，你的大量代码很可能围绕着这种产品的构造，初始化这些细节上面。也因为如此，类似的产品之间有很多可以复用的特征，所以会和模版方法相随。

抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。


举个不太恰当的例子，如果让我设计一款战略游戏，我可能会设计这样的结构


public interface AbstractForceFactory
{

Unit createUnit(int unitTypeId);; //一般单位

Building createBuilding(int buildingTypeId);; //建筑物

Hero createHero(int heroTypeId);; //英雄人物


}


然后再设计出 AllyFactory ,RussianFactory等几个产品线。


至于V3Unit，我可能会去调用一个V3UnitFactory.create()去创建，而这个Factory很可能是从一个abstract的VehicleFactory继承下来


或者设计一个V3UnitBuilder ??


A:----------------------------------------------------------------

嗯，有点明白了。

但是我想知道Factory Method模式和Abstract Factory模式是否有严格的区分界限。

我也来举一个例子：

public abstract class AbstractTerranFactory {

//创建机枪兵
public abstract Marine createMarine();;

//创建喷火兵
public abstract Fireman createFireman();;

//创建医生
public abstract Medical createMedical();;

public void prepare();
{
Marine marine = createTank();;
Fireman fireman = createFireman();;
Medical medical = createMedical();;

//每个士兵首先要训练
marine.training();;
fireman.training();;
medical.training();;

//然后为每个士兵装备
marine.equip();;
fireman.equip();;
medical.equip();;
}
}


现在我为上面得TerranFactory提供一个实现，专门创建某一类机枪兵、喷火兵、医生MM。然后出兵之前，调用TerranFactory.prepare()方法。

好，我的问题来了。现在上述工厂涉及到了“创建一类对象”，但是伴随着创建时，也伴随了一些training，equip方法，用到了Template Method模式。那么现在是使用了Factory Method模式还是Abstract Factory模式？

进一步讲，假如现在我去掉创建喷火兵，医生的方法，只留下创建机枪兵的方法，现在又是Factory Method模式还是Abstract Factory模式？


B:------------------------------------------------------------------------

ok，好像讨论到一些本质上了。为什么是Abstract，因为是抽象的（好像是废话:D ），从FactoryMethod上抽象出来的。我认为每个AbstractFactory创建的都是一条产品线，而这条产品线会有多个子类派生。比如 AbstractTerranFactory ，是否会有或者可能有多种实现方式，比如BlizzardTerranFactory，或者WestWoodTerranFactory，或者 MicrosoftTerranFactory。如果是这样的，那么ok，至少是一种Abstract Factory。

至于你的代码，其实并不矛盾，没有人说一个类只能是一种设计模式的，你完全可以认为你的AbstractTerranFactory 是一个AbstractFactory + FactoryMethod+Template，如果去掉创建喷火兵，医生的方法，只留下创建机枪兵的方法，就不是AbstractFactory。

另:
design patterns一般是在设计阶段考虑的,所以取名design啊(又是一句废话:D ),真正干活的时候,是先看需求,然后考虑这些需求同哪些模式的适用场合匹配.实际开发中对代码修改后,很可能就随之改变了原来的模式特征,这也很正常, 模式之间本来就是可以互相演化和关联的.


C:-----------------------------------------------------------------------------

工厂模式是最重要的模式，因为大多数模式都需要用到工厂模式。如果不能正确的运用工厂模式，那么可以说无法成为合格的架构师。
多数设计模式的内容讲解的都是如何设计接口。
接口如何产生呢？如果在客户代码（类库的使用者称之为客户）中直接使用具体类，那么就失去了接口的意义。因为接口的使用目的，就是要降低客户对具体类的依赖程度。如果在客户代码中直接使用接口，那么就造成了客户对具体类名称的依赖。（客户最终需要以某种方式指明所需要的具体类，如配置文件或代码，但是只需要指出一次，所以说降低对具体类的依赖程度）。要使客户代码不依赖具体类，唯一的方法，就是让客户代码不依赖具体类的部分不知道具体类的名称。知道具体类名称的部分，仅仅是配置部分。（配置文件或者配置代码）。
依赖不可能完全消除，除非二者毫无联系。但是可以将这种依赖的程度降到最低。
既然不能直接创建具体类，那么就需要通过一个创建者类来创建接口的实现类。这样就产生了工厂类。
那么现在已经知道工厂类存在的理由，抽象创建接口的过程。
这样，就可以使用简单工厂。
简单工厂，一般是两级结构。工厂类创建接口。
随着接口创建复杂性的增强，可能在接口创建的过程中，一个创建者类，无法承担创建所有的接口类的职责。
可能会有这样的情况，我们定义了一个接口，有6个实现类分别是123456号。但是，这六个实现类不可能用一个工厂创建出来，因为123号是 windows下的实现，而456号是linux上的实现。（假设我们使用的语言不是广大人民群众热爱的java语言），那么这个时候，我还需要客户方用相同的方式来创建这个借口，而不是在代码中到处写

if (操作系统=="windows");{
...
}
else{
...
}


那样就太麻烦了。设计模式就是为了减少麻烦，而不是什么别的废话，比如什么太极八卦、天人合一、面向xx之类的。因为怕麻烦，所以搞出设计模式这个咚咚减少麻烦。如果你发现用了设计模式更麻烦了，那么肯定是你用错了。
这个时候为了省事，我就把工厂也抽象成一个接口（因为我有两个相似的工厂，如果只有一个，我还废话什么呢），这样就成了工厂方法。
当然，既然工厂方法成了一个接口，那么当然也需要用一个工厂来创建它。这个时候，创建是三级结构，简单工厂（此时是工厂的工厂）创建工厂接口（本来是个类，现在因为进一步的抽象，成为接口了），工厂接口创建产品。
过了一段时间，随着我们的工厂业务不断发展，我们有了很多产品。
比如，我们有锤子和钉子两种产品。这两种产品都有windows品牌和linux品牌的。我们给锤子和钉子各自定义了一个创建的接口。

interface 锤子工厂{
造锤子（）；
}
interface 钉子工厂{
造钉子();;
}


可是，我们发现某些用户，用windows的锤子去敲linux的钉子，从而把程序敲出了bug。这当然是我们的错误，因为我们违反了一条金科玉律：
要想使你的程序稳定运行，你假设用户是猪。
所以，我们把锤子和钉子的工厂合并，让一个工厂只能造出配套的锤子和钉子，这样猪就没有犯错误的机会了。
于是我们搞出一个抽象工厂：
interface 铁匠铺{
造锤子（）；
造钉子();
}
当然，这个铁匠铺是个接口，所以同样需要用一个工厂来创建它。所以，这个时候，工厂还是三级结构。
我们的工厂，业务很多，而且产品一般都是配套使用的（这样可以多骗点钱），所以，我们大多数情况下，都是使用抽象工厂和简单工厂。简单工厂用来创建工厂，抽象工厂创建产品。
工厂的作用，就是创建接口。
其实我们不知道什么是设计模式，我们只是怕麻烦。什么是麻烦呢？
我们觉得把同样的代码写两遍就非常麻烦。所以，我们宁可多写几句，也要解决麻烦。猪不怕麻烦，可以日复一日的重复相同的事情，可是我们不是猪。