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

前言

我一直想介绍下工厂模式,我曾经搞过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++没接口的概念,但你可以模拟接口。这里只介绍简单工厂模式,至于剩下两种工厂模式,我觉得更没有使用价值。

 

[java][/java] view plaincopy

  1. interface Car {
  2.     void drive();
  3. }
  4. class Benz implements Car {
  5.     @Override
  6.     public void drive() {
  7.         System.out.println(“drive Benz”);
  8.     }
  9. }
  10. class Bmw implements Car {
  11.     @Override
  12.     public void drive() {
  13.         System.out.println(“drive Bmw”);
  14.     }
  15. }
  16. class CarFactory {
  17.     public static Car creator(String carType) {
  18.         if (carType.equals(“Benz”)) {
  19.             return new Benz();
  20.         } else if (carType.equals(“Bmw”)) {
  21.             return new Bmw();
  22.         } else {
  23.             throw new UnsupportedOperationException(“car with type” + carType
  24.                     + ” is not supported.”);
  25.         }
  26.     }
  27. }
  28. public class A {
  29.     public static void main(String args[]) {
  30.         Car benz = CarFactory.creator(“Benz”);
  31.         benz.drive();
  32.         Car bmw = CarFactory.creator(“Bmw”);
  33.         bmw.drive();
  34.     }
  35. }

上述代码是没啥用的,看一个实际使用的例子。下面这个工厂模式的意义在于能够统一管理所有的业务管理器,仅此而已。

 

[java][/java] view plaincopy

  1. /**
  2.  * 管理器的工程,初始化所有业务的管理器
  3.  */
  4. public class ManagerFactory {
  5.     // 缓存管理器实例的集合
  6.     private transient Map<Byte, IManager> mManagerMap = null;
  7.     private static ManagerFactory sIntance = new ManagerFactory();
  8.     private ManagerFactory() {
  9.         mManagerMap = new HashMap<Byte, IManager>();
  10.     }
  11.     public ManagerFactory getInstance() {
  12.         return sInstance;
  13.     }
  14.     /**
  15.      * 获取管理器实例
  16.      *
  17.      * @param context  上下文
  18.      * @param mId  管理器ID
  19.      * @return  管理器实例
  20.      */
  21.     protected IManager getManager(final Context context, final byte id) {
  22.         IManager manager = mManagerMap.get(mId);
  23.         if (manager == null) {
  24.             switch (id) {
  25.             case DB_ID:
  26.                 manager = new DBManager(context);
  27.                 break;
  28.             case DOWNLOAD_ID:
  29.                 manager = new DownloadManager(context);
  30.                 break;
  31.             case NETWORK_ID:
  32.                 manager = new NetworkManager();
  33.                 break;
  34.             case IMAGE_ID:
  35.                 manager = new ImageManager();
  36.                 break;
  37.             default:
  38.                 break;
  39.             }
  40.             mManagerMap.put(id, manager);
  41.         }
  42.         return manager;
  43.     }
  44. }

工厂模式为什么没有太大价值

 

1.有利有弊

优点:将对象的创建统一起来便于维护和整体把控,对扩展开放,对修改封闭

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

2.使用有限制

从工厂模式的示例可以看出:工厂模式需要类实现它的接口并且在业务内部存在明显的继承关系,比如汽车和奔驰宝马的关系。而继承关系往往存在于模型之间,业务之间很难存在继承关系,因此如果业务内部或者业务之间没有这种显式的继承关系该咋办?就算业务内部有继承关系,各个业务交给你统一管理,这样就会提高代码的耦合性,当创建逻辑复杂的时候,工厂方法就很复杂,容易产生干扰。

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

可以通过高度层次化和模块化来提高系统的开闭性,而不必生硬地去套用工厂模式。

标签