新的一天开始了，唉又大了；今天因为操作失误，股票少赚了100多，尼玛看来是天意，不过好歹也收益270多只要赚就行，这两天感觉身体好虚弱啊，野蛮的体魄还是需要坚持不懈的锻炼，我又该去体育馆转转了；昨天玩了下工厂方法模式，今天我们再来玩玩抽象工厂模式，说过了要像黄牛犁地一样系统的总结过一遍设计模式；这么做是很有必要的。
抽象工厂模式是工厂方法模式的升级版本，
抽象工厂模式定义:
Provide an interface for creating families of related or dependent objects without specifying
their concrete classes.（为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们
的具体类。）
我们今天还从代码中展开，假如戴尔公司生产两款电脑，每一款型号的电脑针对不同用户群体配置不同，比如有家庭版，旗舰版，商务版，游戏本。我们改怎么办？难道要用工厂方法模式创建4个不同工厂吗，这个时候我们可以用到抽象工厂模式，我们想要的是这个工厂生产旗舰版，另一个工厂生产家庭版；它们具有共同特性，我们只要弄一个工厂生产旗舰版，一个工厂生产家庭版，调用者只要调用不用关心内部如何区分两款不同电脑；Ok 我们写个Demo，
//**戴尔A型号
public abstract class ComputerProductA {
// 产品共有属性，computer 型号
public void getModelNumber() {
}
// 产品相同方法的不同的实现
public abstract void makeComputer();
}
//**戴尔B型号
public abstract class ComputerProductB {
// 产品共有属性，computer 型号
public void getModelNumber() {
}
// 产品相同方法的不同的实现
public abstract void makeComputer();
}
Ok两个电脑产品型号确定了，下面我们确定它的实现类；
public class ComputerProductBFalgShip extends ComputerProductB {
@Override
public void makeComputer() {
System.out.println("生产B型号的旗舰版");
}}
这是产品B旗舰版产品
public class ComputerProductBFamily extends ComputerProductB {
@Override
public void makeComputer() {
System.out.println("生产B型号的家庭版");
}
}
这是产品B家庭版的
哎产品A的同理，我实在不想粘贴代码了；现在我们有了产品就应该定义工厂，工厂是干什么的，当然是生产产品的，所以工厂里面的方法都是为了生产产品而来；两条产品线，我们定义两个工厂；
public abstract class AbstractComputerFactory {
public abstract ComputerProductA createComputerA();
public abstract ComputerProductB createComputerB();
}
旗舰版工厂如下：内部方法都是产出产品
public class ComputerFalgShipFactory extends AbstractComputerFactory {
@Override
public ComputerProductA createComputerA() {
// TODO Auto-generated method stub
return new ComputerProductAFalgShip();
}
@Override
public ComputerProductB createComputerB() {
// TODO Auto-generated method stub
return new ComputerProductBFalgShip();
}
}
家庭版如下：
public class ComputerFamilyFractory extends AbstractComputerFactory {
@Override
public ComputerProductA createComputerA() {
// TODO Auto-generated method stub
return new ComputerProductAFamily();
}
@Override
public ComputerProductB createComputerB() {
// TODO Auto-generated method stub
return new ComputerProductBFamily();
}
}
只不过我们在工厂里提供了两个方法分别生产不同型号的电脑：OK我们开工试试效果：
public static void main(String[] args) {
AbstractComputerFactory create1 = new ComputerFalgShipFactory();
AbstractComputerFactory create2 = new ComputerFamilyFractory();
create1.createComputerA().makeComputer();
create1.createComputerB().makeComputer();
create2.createComputerA().makeComputer();
create2.createComputerB().makeComputer();
}
欧了效果还不错，杠杠的，原来这就是抽象方法模式啊，没错就是这么简单，还是比较常用的，下面我们总结下这种模式的利弊：
缺点:
抽象工厂模式的最大缺点就是产品族扩展非常困难：解释一下，比如我们再增加一个产品，比如F型号的电脑，我们是不是要增加一个工厂呢就会动工厂上层的代码添加一个public abstract ComputerProductC createComputerC();上层动了岂不是钱一发动全身吗；
产品族扩展比较困难;纵向扩展困难横向简单，
优点:
封装性，每个产品的实现类不是高层模块要关心的，它要关心的是什么？是接口，是
抽象，它不关心对象是如何创建出来，这由谁负责呢？工厂类，只要知道工厂类是谁，我就
能创建出一个需要的对象，省时省力，优秀设计就应该如此
