设计模式--简单工厂模式

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

设计原则：

要依赖抽象，不要依赖具体类

目录

本文的结构如下：

• 什么是简单工厂模式
• 为什么要用该模式
• 模式的结构
• 代码示例
• 优点和缺点
• 适用环境
• 模式应用
• 总结

一、前言

工厂模式是一个比较复杂的模式，可以分为三类：

• 简单工厂模式
• 工厂方法模式
• 抽象工厂模式

准确说，简单工厂模式并不属于GoF 23种设计模式，但在软件开发中应用较为频繁，通常将它作为学习其他工厂模式的入门。

二、什么是简单工厂模式

简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

三、为什么要用简单工厂模式

假设你经过深思熟虑，走到老板的办公司，微笑着对老板说：“老板，我是来办理离职的。”老板再三挽留，不舍放走你这个人才，给你涨三倍薪资，你依然面不改色，毅然拒绝了，因为你已经在市中心买下了一家店面，正准备做自己的老板--卖蛋糕。

辞职后，你找我写订蛋糕的相关代码，（现在只有四种蛋糕，芝士蛋糕，水果蛋糕，奶油蛋糕及默认什么也不加的蛋糕），于是我这样写：

/**
 * Created by w1992wishes on 2017/10/31.
 */
public class CakeStore {
    public Cake orderCake(String type) {
        Cake cake;
        if ("cheese".equals(type)) {
            cake = new CheeseCake();
        } else if ("fruit".equals(type)) {
            cake = new FruitCake();
        } else if ("cream".equals(type)) {
            cake = new CreamCake();
        } else {
            cake = new DefaultCake();
        }
        cake.bake();
        cake.box();
        return cake;
    }
}

你新开的蛋糕店卖的很好，想新增加一些品种，比如巧克力蛋糕，于是我需要这样修改：

我把代码修改后给了你，出于负责的态度，你百忙中抽空看了一遍，你惊呆了，你说，“你就是一堆狗屎，这种代码都能写出来？”。

你张大了嘴对我咆哮，口水喷了我一脸，但作为前程序猿，你有着专业的精神，你压着汹涌的怒火，教导我说：

CakeStore类是一个“巨大的”类，在该类的设计中存在如下几个问题：

1. 在CakeStore类orderCake（）中包含很多“if…else…”代码块，代码相当冗长，代码越长，阅读难度、维护难度和测试难度也越大；而且大量条件语句的存在还将影响系统的性能，程序在执行过程中需要做大量的条件判断。
2. CakeStore类orderCake（）的职责过重，它负责初始化所有的蛋糕对象，并且还要进行bake()和box()，将各种蛋糕对象的初始化代码和bake()、box()集中在一个方法中实现，违反了“单一职责原则”，不利于方法的重用和维护。
3. 当需要增加新类型的蛋糕时，必须修改CakeStore类的源代码，违反了“开闭原则”。
4. 如果新开一家蛋糕店，则必须重复写一堆“if...else”代码块用来创建Cake对象，重新写了一堆重复代码。
5. ......

愤怒的你把我辞退，掏出还裹着面粉的手，重操旧业，10分钟，不，只用了2分钟，你就改好了。于是你拍了拍脑袋，懊恼说：“我当时为什么要找那堆狗屎？我可是专业的。”

/**
 * Created by w1992wishes on 2017/10/31.
 */
public class SimpleCakeFacroty {
    public static Cake createCake(String type){
        Cake cake;
        if ("cheese".equals(type)) {
            cake = new CheeseCake();
        } else if ("fruit".equals(type)) {
            cake = new FruitCake();
        } else if ("cream".equals(type)) {
            cake = new CreamCake();
        } else {
            cake = new DefaultCake();
        }
        return cake;
    }
}

你将创建蛋糕的过程挪到了一个叫SimpleCakeFactory类中，于是CakeStore便这样了：

public class CakeStore {
    public Cake orderCake(String type) {
        Cake cake;
        cake = SimpleCakeFacroty.createCake(type);
        cake.bake();
        cake.box();
        return cake;
    }
}

当然看上去只是将创建Cake对象从CakeStore挪到了SimpleCakeFactory，似乎并没有太多变化。如果新增蛋糕似乎还需要新增else if，破坏了“对扩展开放，对修改关闭”的原则。

但简单工厂的加入使蛋糕的生产和蛋糕的使用分开了，同时新开蛋糕店时，也可以重新复用SimpleCakeFactory中的方法，减少了大量重复代码，而且每次新增蛋糕，只需要修改SimpleCakeFactory一个类就好了，这些都是优点呢。

四、简单工厂模式的结构

有了上面的蛋糕店的例子后，再来总结一下简单工厂模式的结构。

在简单工厂模式结构图中包含如下几个角色：

• SimpleFactory（工厂角色）：工厂角色即工厂类，它是简单工厂模式的核心，负责实现创建所有产品实例的内部逻辑；工厂类可以被外界直接调用，创建所需的产品对象；在工厂类中提供了静态的工厂方法createProduct()，它的返回类型为抽象产品类型Product。
• Product（抽象产品角色）：它是工厂类所创建的所有对象的父类，封装了各种产品对象的公有方法，它的引入将提高系统的灵活性，使得在工厂类中只需定义一个通用的工厂方法，因为所有创建的具体产品对象都是其子类对象。
• ConcreteProduct（具体产品角色）：它是简单工厂模式的创建目标，所有被创建的对象都充当这个角色的某个具体类的实例。每一个具体产品角色都继承了抽象产品角色，需要实现在抽象产品中声明的抽象方法。
• 
  在简单工厂模式中，客户端通过工厂类来创建一个产品类的实例，而无须直接使用new关键字来创建对象，它是工厂模式家族中最简单的一员。

五、代码示例

上面蛋糕的例子可以看作一个简单示例，这里简单再列一个：

典型的抽象产品类代码

/**
 * Created by w1992wishes on 2017/11/1.
 */
public abstract class Product {
    public void methodSame() {
        //公共方法的实现  
    }
    //声明抽象业务方法
    public abstract void methodDiff();
}

在具体产品类中实现了抽象产品类中声明的抽象业务方法，不同的具体产品类可以提供不同的实现，典型的具体产品类代码

/**
 * Created by w1992wishes on 2017/11/1.
 */
public class ConcreteProductA extends Product {
    @Override
    public void methodDiff() {
        //业务方法的实现  
    }
}
/**
 * Created by w1992wishes on 2017/11/1.
 */
public class ConcreteProductB extends Product {
    @Override
    public void methodDiff() {
        //业务方法的实现  
    }
}

简单工厂模式的核心是工厂类，在没有工厂类之前，客户端一般会使用new关键字来直接创建产品对象，而在引入工厂类之后，客户端可以通过工厂类来创建产品，在简单工厂模式中，工厂类提供了一个静态工厂方法供客户端使用，根据所传入的参数不同可以创建不同的产品对象，典型的工厂类代码

/**
 * Created by w1992wishes on 2017/11/1.
 */
public class SimpleFactory {
    //静态工厂方法  
    public static Product getProduct(String arg) {
        Product product = null;
        if (arg.equalsIgnoreCase("A")) {
            product = new ConcreteProductA();
            //初始化设置product  
        }
        else if (arg.equalsIgnoreCase("B")) {
            product = new ConcreteProductB();
            //初始化设置product  
        }
        return product;
    }
}

在客户端代码中，我们通过调用工厂类的工厂方法即可得到产品对象，典型代码

class Client {  
    public static void main(String args[]) {  
        Product product;   
        product = Factory.getProduct("A"); //通过工厂类创建产品对象  
        product.methodSame();  
        product.methodDiff();  
    }  
}

六、简单工厂模式的优点和缺点

6.1、简单工厂模式的优点

• 工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。
• 客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。
• 通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

6.2、简单工厂模式的缺点

• 由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
• 使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。
• 系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，同样破坏了“开闭原则”；在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
• 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

七、简单工厂模式的适用环境

在以下情况下可以使用简单工厂模式：

• 工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
• 客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。

八、模式应用

• JDK类库中广泛使用了简单工厂模式，如工具类java.text.DateFormat，它用于格式化一个本地日期或者时间。

public final static DateFormat getDateInstance(); 
public final static DateFormat getDateInstance(int style); 
public final static DateFormat getDateInstance(int style,Locale locale); 

• 获取不同加密算法的密钥生成器。

KeyGenerator keyGen=KeyGenerator.getInstance("DESede");

• 创建密码器。

Cipher cp=Cipher.getInstance("DESede");

九、总结

• 创建型模式对类的实例化过程进行了抽象，能够将对象的创建与对象的使用过程分离。
• 简单工厂模式又称为静态工厂方法模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
• 简单工厂模式包含三个角色：工厂角色负责实现创建所有实例的内部逻辑；抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口；具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。
• 简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。
• 简单工厂模式最大的优点在于实现对象的创建和对象的使用分离，将对象的创建交给专门的工厂类负责，但是其最大的缺点在于工厂类不够灵活，增加新的具体产品需要修改工厂类的判断逻辑代码，而且产品较多时，工厂方法代码将会非常复杂。
• 简单工厂模式适用情况包括：工厂类负责创建的对象比较少；客户端只知道传入工厂类的参数，对于如何创建对象不关心。