再来介绍一下抽象工厂模式（Abstact Factory Pattern），也是创建型模式之一，上篇博客主要介绍了工厂方法模式。抽象工厂模式和工厂方法模式稍有区别。工厂方法模式中工厂类生产出来的产品都是具体的，也就是说每个工厂都会生产某一种具体的产品，但是如果工厂类中所生产出来的产品是多种多样的，工厂方法模式也就不再适用了，就要使用抽象工厂模式了。
　　抽象工厂模式的起源或者最早的应用，是对不同操作系统的图形化解决方案，比如在不同操作系统中的按钮和文字框的不同处理，展示效果也不一样，对于每一个操作系统，其本身构成一个工厂类，而按钮与文字框控件构成一个产品类，两种产品类两种变化，各自有自己的特性，比如 Windows，Unix 和 Mac OS 下的 Button 和 Text 等。所以据此，我们可以初步构建框架：
　　
然后对于 Windows 系统来说需要生成的是 WindowsButton 和 WindowsText 产品类对象，其他两个系统一样也需要对应的对象。为了达到“为创建一组相关或者是相互依赖的对象提供一个接口，而不需要指定它们的具体类”的松散耦合原则，这时使用抽象工厂模式就非常契合。
　　PS：对技术感兴趣的同鞋加群544645972一起交流。

设计模式总目录

　　java/android 设计模式学习笔记目录

特点

　　抽象工厂模式（Abstact Factory Pattern）提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指明具体类。
　　和工厂方法模式一样，抽象工厂模式依然符合“针对抽象编程，不针对具体类编程”的原则，将客户端和具体类解耦，增加扩展性，契合设计模式中的依赖倒置原则和里氏替换原则。

UML类图

　　这里以上面的不同操作系统的图形化解决方案为例来画出 uml 类图（貌似图片宽度被固定死了，在新的标签页中打开该图片即可），
　　
　　虽然抽象工厂模式的类繁多，但是主要还是分为 4 类：

• AbstractFactory：抽象工厂角色（对应 IFactory 接口），它声明了一组用于创建不同产品的方法，每一个方法对应一种产品，如图中的 IFactory 接口就有 createButton 和 createText 方法用于创建 IButton 对象和 IText 对象。
• ConcreteFactory：具体工厂角色（对应 WindowFactory，UnixFactory 和 MacOSFactory 类），它实现了在抽象工厂中定义的创建产品的方法，生成一组具体产品，这些产品构成一个产品种类，每一个产品都位于某个产品等级结构中。
• AbstractProduct：抽象产品角色（对应 IButton 和 IText 接口），他定义了几种产品的基本行为。
• ConcreteProduct：具体产品角色（对应WindowsButton 和 WindowsText 等 6 个实现类），它定义具体工厂生产的具体产品对象，实现抽象产品接口中声明的业务方法。

示例与源码

　　我们直接根据上面的 uml 类图直接构造四个角色：

产品相关类

　　产品类主要是 IButton 接口和其实现子类，IText 接口和其实现子类。IButton 接口和其子类：
IButton.class

public interface IButton {
    void show();
}

WindowsButton.class

public class WindowsButton implements IButton {
    @Override
    public void show() {
        Log.e("show", "this is a Windows button");
    }
}

UnixButton.class

public class UnixButton implements IButton{
    @Override
    public void show() {
        Log.e("show", "this is a Unix button");
    }
}

MacOSButton.class

public class MacOSButton implements IButton{
    @Override
    public void show() {
        Log.e("show", "this is a MacOS button");
    }
}

IText 接口和其实现子类：
IText.class

public interface IText {
    void show();
}

WindowsText.class

public class WindowsText implements IText{
    @Override
    public void show() {
        Log.e("show", "this is a Windows text");
    }
}

UnixText.class

public class UnixText implements IText{
    @Override
    public void show() {
        Log.e("show", "this is a Unix text");
    }
}

MacOSText.class

public class MacOSText implements IText{
    @Override
    public void show() {
        Log.e("show", "this is a MacOS text");
    }
}

工厂相关类

　　上面定义完产品的相关类之后就要定义工厂的相关类了，工厂类的作用主要是用来创建对应的两个产品种类的对象：
IFactory.class

public interface IFactory {
    /**
     * 生成对应按钮
     */
    IButton createButton();

    /**
     * 生成对应文字
     */
    IText createText();
}

WindowsFactory.class

public class WindowsFactory implements IFactory {
    @Override
    public IButton createButton() {
        return new WindowsButton();
    }

    @Override
    public IText createText() {
        return new WindowsText();
    }
}

UnixFactory.class

public class UnixFactory implements IFactory{
    @Override
    public IButton createButton() {
        return new UnixButton();
    }

    @Override
    public IText createText() {
        return new UnixText();
    }
}

MacOSFactory.class

public class MacOSFactory implements IFactory{
    @Override
    public IButton createButton() {
        return new MacOSButton();
    }

    @Override
    public IText createText() {
        return new MacOSText();
    }
}

测试

　　最后的测试程序也很简单：

@Override
public void onClick(View v) {
    switch (v.getId()) {
        case R.id.btn_Windows:
            WindowsFactory windowsFactory = new WindowsFactory();
            windowsFactory.createButton().show();
            windowsFactory.createText().show();
            break;
        case R.id.btn_Unix:
            UnixFactory unixFactory = new UnixFactory();
            unixFactory.createButton().show();
            unixFactory.createText().show();
            break;
        case R.id.btn_MacOS:
            MacOSFactory macOSFactory = new MacOSFactory();
            macOSFactory.createButton().show();
            macOSFactory.createText().show();
            break;
    }
}

对象的日志也能够成功的打印：

总结

　　抽象工厂模式在 Android 源码中的实现相对来说是比较少的，其中一个比较确切的例子是 Android 底层对 MediaPlayer 的创建，具体类图如下所示（在新的标签页中打开该图片即可）：

四种 MediaPlayerFactory 分别会生成不同的 MediaPlayer 基类：StagefrightPlayer、NuPlayerDriver、MidFile 和 TestPlayerStub ，四者均继承于MediaPlayerBase 。
　　抽象工厂的优点有很多，一个显著的优点是分离接口与实现，客户端使用抽象工厂来创建需要的对象，它根本就不知道具体的实现是谁，客户端只是面向产品的接口编程而已，使其从具体的产品实现中解耦，同时基于接口与实现的分离，使抽象工厂模式在切换产品类时更加灵活、容易。
　　当然缺点也是很明显的，第一个也是最明显的就是类文件的大大增多，第二个是如果要扩展新的产品类，就需要去修改抽象工厂类的最下层接口，这就会导致所有的具体工厂类均会被修改。

抽象工厂模式与工厂方法模式对比

　　其实对比一下两种模式的 uml 图，就可以发现其实工厂方法模式是潜伏在抽象工厂模式中的，抽象工厂中的每个方法都可以单独抽出来作为一个工厂方法。抽象工厂的任务是定义一个负责创建一组产品的接口，这个接口内的每个方法都负责创建一个具体产品，同时我们利用实现抽象工厂的子类来提供这些具体的做法，所以在抽象工厂中利用工厂方法来实现生产方法是相当自然的做法。这么一对比，可以知道抽象工厂模式比工厂模式的一个优点就是在它可以将一群相关的产品集合起来。
　　对比一下，使用场景也就清楚了：当需要创建产品家族和想让制造的相关产品集合起来时，使用抽象工厂模式；当仅仅想把客户代码从需要实例化的具体类中解耦，或者如果目前还不明确将来需要实例化哪些具体类时，可以使用工厂方法模式。

源码下载

　　https://github.com/zhaozepeng/Design-Patterns/tree/master/AbstactFactoryPattern

引用

http://blog.csdn.net/jason0539/article/details/44976775
https://en.wikipedia.org/wiki/Abstract_factory_pattern