精雕细琢——全方位解析工厂模式

工厂模式是面向对象设计模式中非常重要，非常流行的模式，是应该首先被理解透彻的模式。

我们讲对象的相关职责包括：

对象本身的职责（数据和行为）
创建对象的职责
使用对象的职责

而对象的创建在Java中有四种方式：

new
反射
clone()
工厂类创建

工厂模式是创建型设计模式

程序员的敏感地带：

大量的重复性代码，大量的if...else...语句
一个类过于复杂，违反了“单一职责原则”
如果有扩展会引发修改，违反了“开闭原则”
使用对象时不要用new来创建对象，耦合度高

我们先描述一个场景，某产品展销会上，用户甲需要了解多种产品的详细情况，他需要自己去根据每个产品名字在地图上查找其陈列位置，然后跑过去挨家看。而此时，待在家里的用户乙也想了解一下这个展销会里面的产品，他给举办此次展销会的厂商丙打了个电话，厂商接待人员说，“你想了解哪个产品，把名字告诉我，我直接就告诉那个产品的情况。”

用户甲自己new完成了产品实例的查找及创建，然后调取了产品的内部详细信息。总共只有一个类，丝毫没有设计可言，所有代码堆砌在这个类中，维护性，灵活性，扩展性，复用性全为0。
用户乙通过工厂类丙创建的方式获得了产品的实例，然后调取了产品的内部详细信息。

上面提到了对象的三种职责，根据“单一职责原则”。

两个类A和B之间的关系应该仅仅是A创建B或者A使用B，而不能是两种都有。

工厂模式就是要增加一层厂商丙来统一管理对象的创建职责，而不是让对象实例化的代码掺杂在多个类中到处都是。

厂商丙的多种实现方式之一：简单工厂模式

定义一个工厂类，增加一个静态方法（所以也叫静态工厂模式），传入不同的参数，内部根据这个参数进行判断，返回不同类的实例，这些被创建实例的类通常都有共同的父类。我们看一下在简单工厂模式中，用户是如何获取一个实例化对象的。

class User {  
    public static void main(String args[]) {
        Book book1 = Factory.createBook("novel");  
        book1.read();
    }
}

而工厂类的内容是：

class Factory {  
    public static Book createBook(String bookType) {
        if("novel".equals(bookType){
            return new NovelBook();  
        }else if("poem".equals(bookType){
            return new PoemBook();  
        }else if("history".equals(bookType){
            return new HistoryBook();  
        }else{
            return null;
        }
    }
}

缺陷：

工厂类内部复杂，有大量if...else...判断
扩展要修改工厂类中的if...else...语句，违反“开闭原则”

厂商丙的多种实现方式之二：工厂方法模式

定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
我们看一下在工厂方法模式中，用户是如何获取一个实例化对象的。

class User {  
    public static void main(String args[]) {
        Factory factory = new NovelBookFactory();
        Book book1 = factory.createBook();
        book1.read();
    }  
}

稍作解读，就是在简单工厂模式里的工厂类的基础上又抽象出一层，将其改为工厂接口Factory，声明一个工厂方法factoryMethod()，而具体产品要有对应的工厂类去实现Factory接口，并重写工厂方法返回对应的具体产品实例。将实例化时机又转移给了用户，用户来决定用哪个具体产品实例。

interface Factory {  
    Book creatBook();
}

class NovelBookFactory implement Factory{  
    Book creatBook(){
        return new NovelBook();
    }
}

这与前面提到的场景中，用户甲也是自己判断然后创建实例是截然不同的，因为工程方法只是让用户决定实例化哪个具体产品，而不会让他去创建，创建的工作还是交给工厂，所以在扩展的时候，当前工厂类，产品类都是不用改动的，只需要再增加一对具体工厂类和具体产品即可。

缺陷：

每次扩展需要增加一对具体工厂类和具体产品类，久而久之，会造成程序中类的数量爆炸。

问题：我们为什么不这样写？

class User {  
    public static void main(String args[]) {
        Book book1 = new NovelBook();
        book1.read();
    }  
}

看上去与上面的工厂方法模式的使用没有任何区别，扩展的时候，也只是需要新增一个子类即可，符合“开闭原则”，但是，这样写是不是就违反了“单一职责原则”呢？我们希望能将具体对象的创建职责通过工厂去管理起来，使程序的可读性更高，也降低类之间的耦合度，不在使用对象时直接new其实例。

厂商丙的多种实现方式之三：抽象工厂模式

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
接着上面的代码改造一下。

class User {  
    public static void main(String args[]) {
        Factory factory = new LuXunBookFactory();
        Prose prose1 = factory.creatProseBook();
        Essay essay1 = factory.creatEssayBook();
        Novel novel1 = factory.creatNovelBook();
        prose1.read();
        essay1.read();
        novel1.read();
    }  
}

class LuXunBookFactory implement Factory{  
    Prose creatProseBook(){//散文
        return new ProseBook();
    }
    Essay creatEssayBook(){//杂文
        return new EssayBook();
    }
    Novel creatNovelBook(){
        return new NovelBook();
    }
}

相较于工厂方法模式，抽象工厂模式将具体工厂类中的具体产品类进行了组合的关联。如上面代码所示，用户要得到的是鲁迅全集的实例，鲁迅全集工厂类就要包括散文，小说和杂文，而这些都是书的子类。如果是工厂方法模式的话，恐怕就要每种书记形式都要建一个自己的工厂类，那实在是庞大至极。程序变得很冗长。所以抽象工厂模式在具体子类中具备一定的关联关系的时候，非常好用。
缺陷：

抽象工厂模式由于将系统又分出一层，利用工厂去管理归并后的“鲁迅全集”，而不是单独管理每个具体类，当扩展时，再出个也是包括散文、小说和杂文的“老舍全集”还好说，只要新增一个老舍全集的类，和一个老舍全集工厂类就好。但是如果“老舍全集”多了诗歌，评论等，那就灾难了，要去修改工厂基类Factory的方法声明，这就违反了“开闭原则”。抽象工厂模式在你确定使用它的那一刻，就要十分确定这个工厂类内部子类的结构是稳定的，不会改变的，否则就不要使用抽象工厂，去用工厂方法模式或许更适合。

我们看到了上面用户在使用工厂模式创建实例时，避免了直接new具体对象实例的方式，但是能否把new LuXunBookFactory()也避免了呢？进一步解耦？
答案是肯定的。

使用反射加配置文件代替new LuXunBookFactory()

我们在创建一个实例的时候，能否直接用字符串本身当做参数来创建对象呢？使用反射就可以达到这个目的。

Factory factory = (Factory) Class.forName("LuXunBookFactory").newInstance();

这样就代替了

Factory factory = new LuXunBookFactory();

那么如果要完全符合“开闭原则”，即用户使用的部分也不去修改，那么就可以采用配置文件的方式。
将字符串"LuXunBookFactory"保存在xml配置文件中。

<?xml version="1.0"?>  
<config>  
    <className>LuXunBookFactory</className>  
</config>

每次利用Java工具XMLUtil类去读取该配置文件，用变量代替原代码中字符串的位置。

工厂方法的隐藏

我们将上面的工厂方法模式用户操作部分粘贴过来看一下：

class User {  
    public static void main(String args[]) {
        Factory factory = new NovelBookFactory();
        Book book1 = factory.createBook();
        book1.read();
    }  
}

interface Factory {  
    Book creatBook();
}

class NovelBookFactory implement Factory{  
    Book creatBook(){
        return new NovelBook();
    }
}

我们发现Book中的read方法应该是直接在基类中声明，所有Book子类去重写具体book方法。那么在用户使用时，这个book方法的调用方法就可以抽象到Factory中去。
当前Factory是接口，接口是无法写方法体的，因此要改为abstract class。

abstract class Factory{
   abstract Book creatBook();
   public void read(){
        Book book = this.creatBook();
        book.read();
    }
}

那么此时，用户在操作时就可以改为

class User {  
    public static void main(String args[]) {
        Factory factory = new NovelBookFactory();
        factory.read();
    }  
}

具体产品工厂类NovelBookFactory中并不需要去管藏方法的事，藏方法一定是在abstract class中放一个具体方法，用于获取当前抽象方法创建的具体子类实例后，直接调用其操作方法。
这样一来，在外部操作的时候，直接用Factory对象就可以调用具体子类里面的操作方法。

三种模式的适用场景

简单工厂模式之所以没有被官方收入，是因为它只是用来学习入门工厂模式的，在实际工作中，很少被使用。
工厂方法模式更适合那种子类之间并没有直接关联关系的结构，没办法，只能每种产品建立一个独立的工厂去创建。
抽象工厂模式就适合那种子类之间有明显的关联关系的结构，将他们拆分归并，仅给一批关联在一起的子类建立一个独立的工厂，它可以批量生产出这批子类的所有实例。

posted @ 2017-09-10 23:35 一面千人阅读(359) 评论(0) 编辑收藏举报

刷新页面返回顶部

一面千人

衣不鲜，体不健，学而时习，悠哉悠哉！