工厂方法模式

工厂方法模式
定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到其子类。
结构和说明：

Product:定义工厂方法所创建的对象的接口，也就是实际需要使用的对象的接口
ConcreteProduct:具体的Product接口的实现对象
Creator:创建器，声明工厂方法
ConcreteCreator:具体的创建器对象，覆盖实现Creator定义的工厂方法，返回具体的Product实例

/**
*工厂方法所创建的对象的接口
*/
public interface Product {
    //可以定义Product的方法
}
/**
*具体的Product对象
*/
public class ConcreteProduct implements Product {
    //实现Product要求的方法
}
/**
*创建器，声明工厂方法
*/
public abstract class Creator {
    //创建Product的工厂方法
    protected abstract Product factoryMethod();
    //示意方法，实现某些功能的方法-----使用了模板方法模式
    public void someOperation() {
        //通常在这些方法实现中，需要调用工厂方法来获取Product对象
        Product product = factoryMethod();
    }
}
/**
*具体的创建器实现对象
*/
public class ConcreteCreator extends Creator {
    public Product factoryMethod() {
        //冲定义工厂方法，返回一个具体的Product对象
        return new ConcreteProduct();
    }
}

工厂方法模式（Factory Method）的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。

工厂方法模式地引进：
简单工厂模式地缺点是对“开闭”原则的支持不够，因为如果有新的产品加入到系统中取，就需要修改工厂类，将必要的逻辑加入到工厂类中。
首先，在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将具体创建的工作交给子类去做。这个核心类摇身一变，成为一个抽象工厂角色
，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。
这种进一步抽象化的过程，使这种工厂方法模式可以用来允许系统在不修改具体工厂角色的情况下引进新的产品。 工厂方法模式涉及到以下四种角色：
1.抽象工厂角色：担任这个角色的是工厂方法模式地核心，它是与应用程序无关的，任何在模式中创建对象的工厂类必须实现这个借口，在实际的系统中，这个角色常常使用抽象java类实现
2.具体工厂角色：担任这个角色的是实现了抽象工厂接口的具体java类，具体工厂角色含有与应用密切相关的逻辑，并且受到应用程序的调用以创建产品对象。
3.抽象产品角色：工厂方法模式所创建的对象的超类，也就是产品对象的共同父类或共同拥有的接口。
4.具体产品角色：这个角色实现了抽象产品角色所声明的接口，工厂方法模式所常见的每一个对象都是某个具体产品角色的实例。
5.客户端角色：创建工厂对象，然后调用工厂对象的工厂方法创建相应的产品对象。

看一个简单的例子

//抽象工厂角色
public interface FruitFactory {
    public Fruit create();
}
//具体工厂角色1
public class AppleFactory implements Factory {
    @Override
    public Fruit create() {
        return new Apple();
    }
}
//具体工厂角色2
public class StrawBerryFactory implements Factory {
    @Override
    public Fruit create() {
        return new StrawBerry();
    }
}
//抽象产品角色
public interface Fruit {
    //种植
    public void plant();
    //生长
    public void grow();
}
//具体产品角色1
public class Apple implements Fruit {
    @Override
    public void grow() {
        System.out.println("Apple is planting.....");
    }

    @Override
    public void plant() {
        System.out.println("Apple is growing......");
    }
}
//具体产品角色2
public class StrawBerry implements Fruit {
    @Override
    public void grow() {
        System.out.println("StrawBerry is planting.....");
    }

    @Override
    public void plant() {
        System.out.println("StrawBerry is growing......");
    }   
}
//客户端
public class Client {
    public static void main(String[] args) {
        //Factory factory = new StrawBerryFactory();
        Factory factory = new AppleFactory();
        Fruit fruit = factory.create();
        fruit.plant();
        fruit.grow();
    }
}

体会工厂方法模式
考虑这样一个实际应用：实现一个导出数据的应用框架，来让客户选择数据的导出方式，并真正执行数据导出。
通常这种系统，在导出数据上，会有一些约定的方式，比如导出成：文本格式、数据库备份形式、Excel格式、Xml格式等等。

不用模板方法模式（类似与简单工厂模式，但是不是返回对象，加入了逻辑，执行了返回的对象的方法）：

/**
*导出的文件对象的接口
*/
public interface ExportFileApi {
    //导出内容成为文件，data为需要保存的数据
    public boolean export(String data);
}
/**
*导出成数据库备份文件形式的对象
*/
public class ExportDB implements ExportFileApi {
    public boolean export(String data) {
        //简单示意一下，这里需要操作数据库和文件
        System.out.println("导出数据"+data+"到数据库备份文件");
        return true;
    }
}
/**
*导出成文本文件形式的对象
*/
public class ExportTxtFile implements ExportFileApi {
    public boolean export(String data) {
        //简单示意一下，这里需要操作文件
        System.out.println("导出数据"+data+"到文本文件");
        return true;
    }
}
/**
*实现导出数据的业务功能对象---类似与简单工厂
*/
public class ExportOperate {
    //导出文件，type:用户选择的导出类型，data:需要保存的数据，return 是否成功导出文件
    public boolean export(int type, String data) {
        //先完成各种导出数据前的准备工作
        //比如进行数据校验
        System.out.println("now 进行数据校验");
        //比如进行数据转换
        System.out.println("new 进行数据转换");
        //比如进行数据格式的封装
        System.out.println("new 进行数据格式的封装");
        //然后才真正的去导出
        ExportFileApi api = null;
        //根据类型来选择究竟要创建哪一种导出文件对象
        if (type == 1) {
            api = new ExportTxtFile();
        } else if (type == 2) {
            api = new ExportDB();
        }

        return api.export(data);
    }
}
//客户端
main() {
    new ExportOperate().export(1, "xxxxxxx");
}

看上去没什么问题，但是存在很多问题：
1.首先ExportOperate的export实现的是业务功能，本来只是想用一下api,也就是说只知道ExportFileApi这个接口，不应该再去承担创建具体对象的功能，在设计上讲就是责任不明确。
2客户端需要传type,这就意味着我们必须把一些实现的细节暴露给客户端，而且因为没有约束type很容易填错，填错了也不知道。
3.今后的扩展很麻烦，如果我想再新增一个ExportFileApi的实现，再去修改ifelse，实在是太麻烦了。违反了开闭原则，对新增开放，对修改关闭。

使用工厂方法模式：

/**
*实现导出数据的业务功能对象
*/
public abstract class ExportOperate {
    //导出文件，type:用户选择的导出类型，data:需要保存的数据，return 是否成功导出文件
    public boolean export(String data) {
        //先完成各种导出数据前的准备工作
        //比如进行数据校验
        System.out.println("now 进行数据校验");
        //比如进行数据转换
        System.out.println("new 进行数据转换");
        //比如进行数据格式的封装
        System.out.println("new 进行数据格式的封装");
        //然后才真正的去导出----使用工厂方法
        ExportFileApi api = factoryMethod();
        return api.export(data);
    }
    //工厂方法，创建导出的文件对象的接口对象
    protected abstract ExportFileApi factoryMethod();
}
/**
*具体的创建器实现对象，实现创建导出成数据库备份文件形式的对象
*/
public class ExportDBOperate extends ExportOperate {
    protected ExportFileApi factoryMethod() {
        //创建导出成数据库备份文件形式的对象
        return new ExportDB();
    }
}
/**
*具体的创建器实现对象，实现创建导出成文本文件形式的对象
*/
public class ExportTxtFileOperate extends ExportOperate {
    protected ExportFileApi factoryMethod() {
        //创建导出成文本文件形式的对象
        return new ExportTxtFile();
    }
}
//客户端
main() {
    //创建需要使用的Creator对象
    ExportOperate exportOperate = new ExportTxtFileOperate();
    //调用输出数据的功能方法
    exportOperate.export("xxxxxxxx");
}

认识工厂方法模式
- 工厂方法模式的功能
工厂方法的注意功能是让父类在不知道具体实现的情况下，完成自身的功能调用，而具体的实现延迟到子类来实现。—-类似于模板方法模式
- 实现成抽象类
工厂方法的实现中，通常父类会是一个抽象类，里面包含所创建所需对象的抽象方法，这些抽象方法就是工厂方法
什么情况下使用抽象方法：既要约束子类的行为，又要为子类通过公共的功能
- 实现成具体的类
也可以把父类实现成为一个具的类，这种情况下，通常是在父类中提供获取所需对象的默认实现方法，这样就算没有具体的子类，也能够运行。—-类似于模板方法模式
- 工厂方法的参数和返回值
工厂方法的实现中，可能需要参数，以便决定到底选用哪一种具体的实现。一般工厂方法返回的是被创建对象的接口对象，当然也可以是抽象类或者一个具体的类的实例。
- 谁来使用工厂方法创建的对象
（1）在工厂方法模式里面，应该是Creator中的其他方法在使用工厂方法创建的对象
（2）客户端应该是使用Creator对象，或者是使用由Creator创建出来的对象，这个时候工厂方法创建的对象，是Creator中的某些方法使用。
（3）在某些情况下，客户端可能会使用由Creator创建出来的对象，这个时候工厂方法创建的对象，是构成客户端需要的对象的一部分

看一个例子：
public class ABC {
    private String name = "";
    private ExportFileApi api = null;
    public ABC(String name, ExportFileApi api) {
        this.name = name;
        this.api = api;
    }
    public void test() {
        System.out.println("name"+name);
        this.api.export("ABC");
    }
}
public class ExportOperate {
    public ABC createABC(String name) {
        return new ABC(name, factoryMethod());
    }
    protected abstract ExportFileApi factoryMethod();
}
main() {
    ExportOperate operate = new ExportTxtFileOperate();
    ABC abc = operate.createABC("xx");
    abc.test(); 
}

public interface Product {}
//客户端使用Creator对象的情况下，Creator的基本实现结构
public abstract class Creator {
    //工厂方法，一般不对外
    protected abstract Product factoryMethod();
    //提供给外部使用的方法，客户端一般使用Creator提供的这些方法来完成所需要的功能
    public void someOperatior() {
        //在这里使用工厂方法
        Product p = factoryMethod();
    }
}

在工厂方法模式里面，客户端要么使用Creator对象，要么使用Creator创建的对象，一般客户端不直接使用工厂方法。当然也可以直接把工厂方法暴露给客户端操作，但是一般不这么做。

Collection中的iterator方法 java.util.Collection 接口中定义了一个抽象的 iterator()
方法，该方法就是一个工厂方法。 对于 iterator() 方法来说 Collection 就是一个根抽象工厂，下面还有 List
等接口作为抽象工厂，再往下有 ArrayList 等具体工厂。 java.util.Iterator 接口是根抽象产品，下面有
ListIterator 等抽象产品，还有 ArrayListIterator 等作为具体产品。 使用不同的具体工厂类中的 iterator
方法能得到不同的具体产品的实例。

• 工厂方法模式与IoC/BI

• 概念
  依赖注入：应用程序依赖容器创建并注入它所需要的外部资源
  控制反转：容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。
  其实IoC/DI对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC/DI容器来创建并注入它所需要的资源了。松散耦合，应用程序A和应用程序B之间就没有直接联系了，在使用容器前的一群散兵变成了有统帅的精兵。
  这么小小的一个改变其实是编程思想的一个大进步，这样就有效的分离了对象和它所需要的外部资源，使得它们松散耦合，有利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。

• 工厂方法模式和IoC/DI的关系
  它们的思想很类似，都是主动变被动，进行主从换位，从而获得更灵活的程序结构。

• 平行的类层次结构
  1）什么是平行的类层次结构呢？
  简单点说，假如有两个类层次结构，其中一个类层次中的每个类在另一个类层次中都有一个对应的类的结构，就被称为平行的类层次结构。A-a1-a2-a3 B-b1-b2-b3，一般来说a1和b1是有关系的。
  2）这种平行的类层次结构用来干什么呢？
  主要用来把一个类层次中的某些行为分离出来，让类层次中的类把原本属于自己的职责，委托给分离出来的类去实现，从而使得类层次本身变得更简单，更容易扩展和复用。
  3）工厂方法模式跟平行的类层次结构有何关系呢？
  可以使用工厂方法模式来连接平行的类层次。

工厂方法模式的优缺点：
1. 可以在不知具体实现的情况下编程
2. 更容易扩展对象的新版本
3. 连接平行的类层次
4. 具体产品对象和工厂方法的耦合性

工厂方法模式的本质
工厂方法模式的本质是：延迟到子类来选择实现

对设计原则的体现
工厂方法模式很好的体现了“依赖倒置原则”
依赖倒置原则告诉我们“要依赖抽象，不要依赖于具体类”，简单点说就是：不能让高层组件依赖于低层组件，而且不管高层组件还是低层组件，都应该依赖于抽象。

何时选用工厂方法模式
1. 如果一个类需要创建某个接口的对象，但是又不知道具体的实现，这种情况可以选用工厂方法模式，把创建对象的工资延迟到子类去实现
2. 如果一个类本身就希望，由它的子类来创建所需的对象的时候，应该使用工厂方法模式

同类文章：
【JDK中的工厂方法模式】http://blog.youkuaiyun.com/bluetjs/article/details/52442172
http://blog.youkuaiyun.com/jason0539/article/details/23020989