为何工厂模式是华而不实的—浅谈工厂模式的利与弊

转载请注明出处：http://blog.csdn.net/singwhatiwanna/article/details/17428923

说明：博主虚心接受你们的抨击，批评，指正

前言

我一直想介绍下工厂模式，我曾经搞过J2EE，用的是轻量级SSH框架，其中Spring有IOC概念，能够称之为控制反转或者依赖注入，在系统开发中，IOC能够很好的替代工厂模式。若干年前，我只用过IOC，并无用过工厂模式，可是工厂模式这个概念倒是给我留下了深深的印象，毕竟，它是我所据说过第一个设计模式，我想它应该是很强大的吧。可是，事情不是我想的那个样子的，在我以前所参与的项目（Android）中几乎没有工厂模式的身影，仅仅是有一个项目采用了简单工厂模式去管理全部的业务管理器。后来，我开始仔细研究工厂模式，发现工厂模式是让我失望的。工厂模式有三种实现方式：简单工厂、工厂方法和抽象广场，除了简单工厂我还发现了一点使用价值外，后二者我基本没发现有啥可以使用价值。也许个人理解还不够透彻，可是目前网上存在的大部分介绍工厂模式的文章都体现了一点：华而不实，难以实际应用。一篇文章不能清晰的介绍一个概念，不能清晰的说明为何要使用这个东西以及如何使用这个东西，那么这篇文章不算好文章的。我目前所看到的关于工厂模式的介绍都是不充分的，包括我写的这篇，期待真正的好文章出现。下面将介绍简单工厂模式以及一个实际项目中使用的例子，后面我将会简单阐述个人观点：为何工厂模式是华而不实的。

简单工厂模式

1.为何要使用工厂模式

直接目的：避免在代码中出现大量的new关键字

根本目的：将对象的建立统一块儿来便于维护和总体把控

这一点能够理解，加入你在项目中new了某个对象100次，一年后因为业务逻辑变动，构造方法多了一个参数，你会怎么办？你应该会这么作：找到这100个对象new的地方，用新的构造方法来建立对象，你重复劳动了100次，假如采用工厂模式，你只用改一次：把建立工厂给改一下就行了。这就是工厂模式最简单最直接的好处。

2.工厂模式的示例

下面是最多见的一个示范，其实它的原理就是面向对象中的多态+接口编程，虽然返回的都是Car类型，可是drive的时候会调用真正的实例中的对应方法。按照抽象类和接口的意义归属，Car应该被定义成抽象类，由于Benz、Bmw和Car的关系是继承关系，而接口表示的一组行为。可是，为何这里还要定义成接口，是由于Java和.NET不支持多继承，若是继承了Car，就没法继承其余类，有时候业务须要必须继承其余类，这个时候代码就不能用了。固然，C++中支持多继承，所以能够在C++中使用抽象类，另外C++没接口的概念，但你能够模拟接口。这里只介绍简单工厂模式，至于剩下两种工厂模式，我以为更没有使用价值。

interface Car {
    void drive();
}

class Benz implements Car {

    @Override
    public void drive() {
        System.out.println("drive Benz");
    }

}

class Bmw implements Car {

    @Override
    public void drive() {
        System.out.println("drive Bmw");
    }

}

class CarFactory {
    public static Car creator(String carType) {
        if (carType.equals("Benz")) {
            return new Benz();
        } else if (carType.equals("Bmw")) {
            return new Bmw();
        } else {
            throw new UnsupportedOperationException("car with type" + carType
                    + " is not supported.");
        }
    }
}

public class A {
    public static void main(String args[]) {
        Car benz = CarFactory.creator("Benz");
        benz.drive();
        Car bmw = CarFactory.creator("Bmw");
        bmw.drive();
    }
}

上述代码是没啥用的，看一个实际使用的例子。下面这个工厂模式的意义在于可以统一管理全部的业务管理器，仅此而已。

/**
 * 管理器的工程，初始化全部业务的管理器
 */
public class ManagerFactory {
    // 缓存管理器实例的集合
    private transient Map<Byte, IManager> mManagerMap = null;

    private static ManagerFactory sIntance = new ManagerFactory();

    private ManagerFactory() {
        mManagerMap = new HashMap<Byte, IManager>();
    }

    public ManagerFactory getInstance() {
        return sInstance;
    }

    /**
     * 获取管理器实例
     * 
     * @param context  上下文
     * @param id  管理器ID
     * @return  管理器实例
     */
    protected IManager getManager(final Context context, final byte id) {
        IManager manager = mManagerMap.get(mId);

        if (manager == null) {
            switch (id) {
            case DB_ID:
                manager = new DBManager(context);
                break;
            case DOWNLOAD_ID:
                manager = new DownloadManager(context);
                break;
            case NETWORK_ID:
                manager = new NetworkManager();
                break;
            case IMAGE_ID:
                manager = new ImageManager();
                break;
            default:
                break;
            }
            mManagerMap.put(id, manager);
        }

        return manager;
    }
}

工厂模式为何没有太大价值

1.有利有弊

优势：将对象的建立统一块儿来便于维护和总体把控，对扩展开放，对修改封闭

缺点：耦合性提升，因为工厂类集中了全部实例的建立逻辑，违反了高内聚责任分配原则，将所有建立逻辑集中到了一个工厂类中,这种对条件的判断和对具体产品类型的判断交错在一块儿，很难避免模块功能的蔓延，对系统的维护和扩展很是不利。

2.使用有限制

从工厂模式的示例能够看出：工厂模式须要类实现它的接口而且在业务内部存在明显的继承关系，好比汽车和奔驰宝马的关系。而继承关系每每存在于模型之间，业务之间很难存在继承关系，所以若是业务内部或者业务之间没有这种显式的继承关系该咋办？就算业务内部有继承关系，各个业务交给你统一管理，这样就会提升代码的耦合性，当建立逻辑复杂的时候，工厂方法就很复杂，容易产生干扰。

3.其开闭性优势很容易被替代

能够经过高度层次化和模块化来提升系统的开闭性，而没必要生硬地去套用工厂模式。