抽象工厂模式

本文来自：曹胜欢博客。http://blog.csdn.net/csh624366188/article/details/7462143

==============================

抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对象。根据LSP原则，任何接受父类型的地方，都应当能够接受子类型。因此，实际上系统所需要的，仅仅是类型与这些抽象产品角色相同的一些实例，而不是这些抽象产品的实例。换言之，也就是这些抽象产品的具体子类的实例。工厂类负责创建抽象产品的具体子类的实例。

先来认识下什么是产品族：位于不同产品等级结构中，功能相关联的产品组成的家族。还是让我们用一个例子来形象地说明一下吧。

图中的BmwCar和BenzCar就是两个产品树（产品层次结构）；而如图所示的BenzSportsCar和BmwSportsCar就是一个产品族。他们都可以放到跑车家族中，因此功能有所关联。同理BmwBussinessCar和BenzSportsCar也是一个产品族。

抽象工厂模式中的有以下的四种角色：

抽象工厂（AbstractFactory）角色：担任这个角色的是工厂方法模式的核心，它是与应用系统商业逻辑无关的。

具体工厂（ConcreteFactory）角色：这个角色直接在客户端的调用下创建产品的实例。这个角色含有选择合适的产品对象的逻辑，而这个逻辑是与应用系统的商业逻辑紧密相关的。

抽象产品（AbstractProduct）角色：担任这个角色的类是工厂方法模式所创建的对象的父类，或它们共同拥有的接口。

具体产品（ConcreteProduct）角色：这个角色用以代表具体的产品。

AbstractFactory模式的结构：

抽象工厂模式就相当于创建实例对象的new，由于经常要根据类生成实例对象，抽象工厂模式也是用来创建实例对象的，所以在需要新的事例对象时便可以考虑是否使用工厂模式。虽然这样做可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。

举例来说：生产餐具和相应食物的工厂，有两个车间，其中一个车间用以生产餐具，一个车间用以生产相应的食物。

当消费者消费时，只需要向相应的具体工厂请求具体餐具和具体食物便可以使用餐具消费食物。

使用UML图表示以上的描述如下：

图1抽象工厂与具体工厂

图2抽象餐具与具体餐具（生产车间）

图3抽象食物与具体食物

注：图中厨房单词写错了：kitchen

每个具体工厂生产出来的具体产品根据不同工厂的不同各不相同，但是客户使用产品的方法是一致的。比如客户在得到餐具和食物之后，两者的搭配是正确的（使用汤匙喝牛奶，使用刀子切面包）。

在本例子中有3个具体工厂AKitchen，BKitchen，BKitchen，分别生产牛奶和汤匙、面包和刀、肉和叉子。牛奶、面包和肉都实现了食物接口。汤匙、刀和叉子都实现了餐具接口。

抽象工厂的接口定义如下所示；

 package abstractFactory;

public interface KitchenFactory{

   public Food getFood();

   public TableWare getTableWare();

}

抽象餐具的接口定义如下所示：

package abstractFactory;

public interface TableWare{

 public String getTool();

}

抽象事物的接口定义如下所示：

package abstractFactory;

public interface Food{

   public String getEatable();

}

而具体的实现也非常简单，以AKitchen为例子

具体工厂AKitchen的定义如下所示；

package abstractFactory;

public class AKitchenimplements KitchenFactory{

   public Food getFood(){

      return new Milk();

   }

   public TableWare getTableWare(){

      return new Spoon();

   }

}

 

具体餐具(spoon)的定义如下所示：

package abstractFactory;

public class Spoonimplements TableWare{ 

   public String getTool() {

      return "spoon";

   }

}

具体食物(milk)的定义如下所示：

package abstractFactory;

public class Milkimplements Food{

   public String getEatable(){

      return "milk";

   }

}

客户端的定义如下：

package abstractFactory;

public class Client{

   public void eat(KitchenFactory k){

      System.out.println("A person eat "+k.getFood().getEatable()

             +" with "+k.getTableWare().getTool()+"!");

   }

   public static void main(String[] args){

      Client client=new Client();

      KitchenFactory kf =new AKitchen();

      client.eat(kf);

      kf=new BKitchen();

      client.eat(kf);

      kf=new CKitchen();

      client.eat(kf);

   }

}

package abstractFactory;

public interface KitchenFactory{

public Food getFood();

public TableWare getTableWare();

}

抽象餐具的接口定义如下所示：

package abstractFactory;

public interface TableWare{

public String getTool();

}

抽象事物的接口定义如下所示：

package abstractFactory;

public interface Food{

public String getEatable();

}

而具体的实现也非常简单，以AKitchen为例子

具体工厂AKitchen的定义如下所示；

package abstractFactory;

public class AKitchenimplements KitchenFactory{

public Food getFood(){

return new Milk();

}

public TableWare getTableWare(){

return new Spoon();

}

}



具体餐具(spoon)的定义如下所示：

package abstractFactory;

public class Spoonimplements TableWare{

public String getTool() {

return "spoon";

}

}

具体食物(milk)的定义如下所示：

package abstractFactory;

public class Milkimplements Food{

public String getEatable(){

return "milk";

}

}

客户端的定义如下：

package abstractFactory;

public class Client{

public void eat(KitchenFactory k){

System.out.println("A person eat "+k.getFood().getEatable()

+" with "+k.getTableWare().getTool()+"!");

}

public static void main(String[] args){

Client client=new Client();

KitchenFactory kf =new AKitchen();

client.eat(kf);

kf=new BKitchen();

client.eat(kf);

kf=new CKitchen();

client.eat(kf);

}

}

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

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

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

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

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