设计模式之工厂方法模式

最近比较忙，每天忙着co项目的代码，没时间更新博客，本来设想每周更两篇，一晃一周就过去了，一篇都没写，今天周末，抓紧写点东西，下午继续co。

过去一周主要研究了一下设计模式中的工厂方法模式，包括普通的工厂方法和抽象工厂方法。说实话，目前对工厂方法还不是很掌握，没有理解其精髓，写点笔记mark 一下。

所谓工厂方法，最主要的作用是生成对象，首先定义对象的抽象接口，然后由一个工厂类来生成对象。在《设计模式之禅》中给出的工厂方法代码清单如下：

public abstract class Product {    // 产品类的公共方法    public void method1() {    // 业务逻辑    }    // 抽象方法    public abstract void method2();}public class ConcreteProduct1 extends Product {    public void method2() {        // 业务逻辑处理    }}public class ConcreteProduct2 extends Product {    public void method2() {        // 业务逻辑处理        }}public abstract class Creator {    public abstract<T extends Product> T createProduct (Class <T>c);}public class ConcreteCreator extends Creator {    public <T extends Product>T createProduct (Class<T>c) {        Product product = null;         try {             product = (Product) Class.forName(c.getName()).newInstance();         } catch (Exception e) {         }         return (T)product;    }}public class client {    public static void maint(String[] args) {        Creator creator = new ConcreteCreator();        Product product = creator.createProdct(ConcreteProduct1.class);    }}

先说说工厂方法的有点吧，《设计模式之禅》中是这样描述的：良好的封装性，扩展性非常优秀，屏蔽产品类，典型的解耦框架。对之前提到的迪米特法则，依赖倒置原则，里氏替换原则都是符合的。

从上面的代码清单来看，其实我们只需要new 出一个商品而已，似乎不需要大费周章的搞个工厂类，直接new 出来不就完了，不是更简单么？确实是这样，“工厂方法模式是new一个对象的替代品，所有需要生成对象的地方都可以使用”--<设计模式之禅> 但书中也提到：需要慎重地考虑是否要增加一个工厂类进行管理，增加代码的复杂度！确实，本来可以直接用的地方增加一堆工厂代码，代码复杂度和代码量都增加了。我想这就是现在很多人对设计模式的误解之一，有的人总感觉设计模式是在做一些多余的事情，本来代码可以直接写出来，非要增加这样或者那样的结构来实现，让开发的难度增加了。首先我觉得，开发本身就应该是一件复杂有难度的事情。跟写作类似。看起来那些大作家，文豪是信手拈来的文章，但是深究起来，人家也是用了各种遣词造句，语文课还要专门学习大师的方法。所以写代码也是需要慎重考虑，认真构思的。该复杂的地方复杂，该简单的地方简单。

扯的有点远了，继续聊工厂方法，对于需要灵活可扩展的框架的时候就可以采用工厂方法。这里强调需要灵活可扩展。当我们抽象出一个接口的时候就已经是考虑到了可能的扩展或者为变化留有余地了，这个时候使用工厂方法屏蔽掉对象生成的细节，对以后的变化提供了便利。如果要增加一个产品类，只需要扩展一个Product3出来就好了，上层的业务逻辑结构都不需要变化。所以工厂方法还是非常有用的。

还有一些工厂方法的扩展：简单工厂模式，多个工厂模式，单例模式，延迟初始化，目前还没有特别的用到过，在往后的学习工作中再详细分析。