每日设计模式——工厂模式之一（简单工厂模式）

工厂模式

以下内容来自百度百科，个人认为其可以作为一个很好的引子来讲述工厂模式，故将其贴在这。

工厂模式是我们最常用的实例化对象模式了，是用工厂方法代替new操作的一种模式。工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑使用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。

工厂模式定义

我们以类Sample为例，如果我们要创建Sample的实例对象:

Sample sample=new Sample();

可是，实际情况是，通常我们都要在创建sample实例时做点初始化的工作,比如赋值查询数据库等。

首先，我们想到的是，可以使用Sample的构造函数，这样生成实例就写成:

Sample sample=new Sample(参数);

但是，如果创建sample实例时所做的初始化工作不是像赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了（就需要Refactor重构）。

为什么说代码很难看，初学者可能没有这种感觉，我们分析如下，初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有悖于Java面向对象的原则，面向对象的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来(减少段和段之间耦合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。

在本例中，首先，我们需要将创建实例的工作与使用实例的工作分开, 也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了，不能再用上面简单new Sample(参数)。还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.Sample是接口,有两个子类MySample 和HisSample .我们要实例化他们时,如下:

ISample mysample=new MySample();

ISample hissample=new HisSample();

随着项目的深入,Sample可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.

但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.

简单工厂模式

简单工厂模式是创建对象实例的工厂模式最简单的实现，只要实现一个工厂类，并在工厂类中创建对象并返回即可。其类图结构如下：

以下是简单的代码实现：

public class Factory {
    public static void main(String[] args) {
        IProduct productA = InstanceFactory.getInstance("A");
        IProduct productB = InstanceFactory.getInstance("B");
    }
}

interface IProduct {

}

class ProductA implements IProduct {

}

class ProductB implements IProduct {

}

class InstanceFactory {
    public static IProduct getInstance(String type) {
        if (type.equals("A")) {
            return new ProductA();
        }
        if (type.equals("B")) {
            return new ProductB();
        }
        return null;
    }
}

工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。

虽然避免了在业务代码中直接new对象，但是由于工厂类集中了所有实例的创建逻辑，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。

当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；并且随着类的增多，判断逻辑也会越来越复杂，那么能否改进工厂类，避免产品类增多而对工厂类进行修改的尴尬局面呢？换句话说，就是不管你创建啥样的产品类，只要你实现的接口是相同的，我都能给你创建出你想要的对象。且看下边对工厂类的改进：

class InstanceFactory_new {
    public static IProduct getInstance(Class<? extends IProduct> clazz) throws IllegalAccessException, InstantiationException {
        return clazz.newInstance();
    }

public class Factory {
    public static void main(String[] args) throws InstantiationException, IllegalAccessException {
//        IProduct productA = InstanceFactory.getInstance("A");
//        IProduct productB = InstanceFactory.getInstance("B");
        IProduct productA = InstanceFactory_new.getInstance(ProductA.class);
        IProduct productB = InstanceFactory_new.getInstance(ProductB.class);
        System.out.println(productA);
    }
}

经过上述改进，不管增加多少产品类的子类，工厂类已经可以不用修改就能轻松完成对象的创建工作了。但是其也存在问题：用户需要告诉工厂类创建哪个类的实例，灵活性相对差一点。

使用场景

工厂类负责创建的对象比较少；

客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心。