工厂方法模式简单介绍

工厂方法模式是创建型设计模式之一。工厂方法模式是一种结构简单的模式，其在我们平时开发中应用很广泛。如 Android 中的 Activity 里的各个生命周期方法，以 onCreate 方法为例，它就可以看作是一个工厂方法，我们在其中可以构造我们的 View 并通过 setContentView 返回给 framework 处理等。

工厂方法模式的定义

定义一个用于创建对象的接口，让子类决定实例化那个类

工厂方法模式的使用场景

在任何需要生成复杂对象的地方，都可以使用工厂方法模式。复杂对象适合使用工厂模式，用 new 就可以完成创建的对象无需使用工厂模式。

工厂方法模式的 UML 类图

角色介绍：

• Factory：抽象工厂，其为工厂方法模式的核心；
• ConcreteFactory：具体工厂，其实现了具体的业务逻辑；
• Product：抽象产品，是工厂方法模式所创建的产品的父类；
• ConcreteProduct：具体产品，为实现抽象产品的某个具体产品的对象。

其实通过上面的 UML 类图，我们可以得出一套 工厂方法模式的通用代码：

//抽象产品类
public abstract class Product {/*** 产品类的抽象方法，由具体的产品类去实现*/public abstract void method();
}//具体产品类A
public class ConcreteProductA extends Product {@Overridepublic void method() {Log.d("Product","我是具体的产品A");}
}//具体产品类B
public class ConcreteProductB extends Product {@Overridepublic void method() {Log.d("Product","我是具体的产品B");}
}//抽象工厂
public abstract class Factory {/*** 抽象工厂方法，具体生产什么产品由子类去实现* @return*/public abstract Product createProduct();
}//具体工厂类
public class ConcreteFactory extends Factory {@Overridepublic Product createProduct() {return new ConcreteProduct();}
}//客户类
public class Client {public static void main(){Factory factory = new ConcreteFactory();Product product = factory.createProduct();product.method();}
}

上述的代码中我们在 Client 类中构造了一个工厂对象，并通过其生产了一个产品对象，这里我们得到的产品对象是 ConcreteProductA 的实例，如果想得到 ConcreteProductB 的实例，更改 ConcreteFactory 中的逻辑即可：

//具体工厂类
public class ConcreteFactory extends Factory {@Overridepublic Product createProduct() {
//        return new ConcreteProductA();return new ConcreteProductB();}
}

这种方式比较常见，需要哪一个产品就生产哪一个，有时候也可以利用反射的方式更简洁地来生产具体产品对象，此时，需要在工厂方法的参数列表中传入一个 Class 类来决定是哪一个产品类：

//抽象工厂
public abstract class Factory {/*** 抽象工厂方法，具体生产什么产品由子类去实现** @return*/public abstract <T extends Product> T createProduct(Class<T> clazz);
}//具体工厂类
public class ConcreteFactory extends Factory {@Overridepublic <T extends Product> T createProduct(Class<T> clazz) {Product p = null;try {p = (Product) Class.forName(clazz.getName()).newInstance();} catch (InstantiationException e) {e.printStackTrace();} catch (IllegalAccessException e) {e.printStackTrace();} catch (ClassNotFoundException e) {e.printStackTrace();}return (T) p;}
}

最后再来看看 Client 中的实现：

//客户类
public class Client {public static void main() {Factory factory = new ConcreteFactory();Product product = factory.createProduct(ConcreteProductB.class);product.method();}
}

需要哪一个类的对象就传入哪一个类的类型即可，这种方法比较简洁、动态。

当我们的工厂只有一个的时候，我们还是为工厂提供了一个抽象类，那么，我们是否可以将其简化掉呢？如果确定你的工厂类只有一个，那么简化掉抽象类是没有问题的，我们只需要将对应的工厂方法改为静态方法即可：

//具体工厂类
public class Factory{@Overridepublic static <T extends Product> T createProduct(Class<T> clazz) {Product p = null;try {p = (Product) Class.forName(clazz.getName()).newInstance();} catch (InstantiationException e) {e.printStackTrace();} catch (IllegalAccessException e) {e.printStackTrace();} catch (ClassNotFoundException e) {e.printStackTrace();}return (T) p;}
}

向这样的方式又称为简单工厂模式或静态工厂模式，它是工厂方法模式的一个弱化版本。

其实到这里大家应该可以发现，工厂方法模式是完全符合设计原则的，其降低了对象之间的耦合度，而且，工厂方法模式依赖于抽象的架构，其将实例化的任务交由子类去完成，有非常好的扩展性。

这里说一下我刚开始对工厂方法模式的简单理解：我刚开始接触到工厂方法模式的时候，觉得非常非常麻烦，看上去工厂方法模式不就是在创建一个产品的实例么？我直接在客户端中进行初始化不就完事了么？用得着又是创建工厂又是创建产品的，好麻烦…其实如果你没有使用工厂方法模式：打个比方，你在 A 界面通过 new 的方式创建了一个咱们上面代码中的 ConcreteProductA 的实例，这样看上去是比使用工厂方法模式要简单的多，但是，如果你在界面B、C、D、E等等界面中都是用到了 ConcreteProductA 这个对象呢？是，你可能会说，那也好办啊，直接创建不就行了。但是你有没有考虑过这么一种情况，如果说现在的 ConcreteProductA 的构造逻辑改变了，那你是不是需要在所有采用 new ConcreteProductA 的地方都要动代码，而使用 工厂方法模式就不会，应为 产品类的创建是在工厂中进行创建的，我只需要改一下工厂方法的逻辑即可；这是一方面，其实还有一个好处：就拿咱们上面的例子来说吧，现在有 A、B两个产品，如果没有采用工厂方法模式，那么我们需要手动创建产品A和产品B的实例，如果说后面我不想使用产品A和产品B了，我这边要出一个新产品C，那么你通过 new 创建产品Ａ、B的地方是不是还是要改？而工厂方法模式就不用，我只需要在工厂方法中将产品 C 返回即可。这就是工厂方法的最大优点。

工厂方法模式的实战

这里以一个生活中的小例子来说明。比如说你是一家汽车生产厂的厂长，对你来说，组装汽车没什么好神秘的，无非就是将一些进口的核心部件，比如发动机和一些国内的零部件组装起来，你的汽车厂主要就是组装某款 SUV 车型，比如 Q3、Q5、Q7，对于这类车型来说，内部结构差异并不是很大，因此，对你来说，一条生产线足以应付 3 种车型，对于这类生产线可以提供这么一个抽象类定义：

public class AudiFactory {public static <T extends AudiCar> T createAudiCar(Class<T> clazz) {AudiCar audiCar = null;try {audiCar = (AudiCar) Class.forName(clazz.getName()).newInstance();} catch (InstantiationException e) {e.printStackTrace();} catch (IllegalAccessException e) {e.printStackTrace();} catch (ClassNotFoundException e) {e.printStackTrace();}return (T) audiCar;}
}

对于这 3 种车型，除了一些车都有的基本共性外，还提供了自动巡航功能，使用一个抽象基类来声明：

public abstract class AudiCar {/*** 汽车的抽象产品类* 定义汽车的一个行为方法，车可以启动开走*/public abstract void drive();/*** 汽车的抽象产品类* 定义汽车的一个行为方法，车可以自动巡航*/public abstract void selfNavigation();
}

接下来就是生产每一种具体的车型了：

public class AudiQ3 extends AudiCar {@Overridepublic void drive() {Log.d("AudiCar","Q3 启动啦！");}@Overridepublic void selfNavigation() {Log.d("AudiCar","Q3 开启自适应巡航！");}
}public class AudiQ5 extends AudiCar {@Overridepublic void drive() {Log.d("AudiCar", "Q5 启动啦！");}@Overridepublic void selfNavigation() {Log.d("AudiCar", "Q5 开启自适应巡航！");}
}public class AudiQ7 extends AudiCar {@Overridepublic void drive() {Log.d("AudiCar","Q7 启动啦！");}@Overridepublic void selfNavigation() {Log.d("AudiCar","Q7 开启自适应巡航！");}
}

最后我们将个各类组装起来形成一条完整的流水线：

public class Test {public static void main() {AudiQ3 audiQ3 = AudiFactory.createAudiCar(AudiQ3.class);audiQ3.drive();audiQ3.selfNavigation();AudiQ5 audiQ5 = AudiFactory.createAudiCar(AudiQ5.class);audiQ5.drive();audiQ5.selfNavigation();AudiQ7 audiQ7 = AudiFactory.createAudiCar(AudiQ7.class);audiQ7.drive();audiQ7.selfNavigation();}
}

总结

总的来说，工厂方法模式是一个很好的设计模式，但是缺点也是难以避免的，每次我们为工厂方法模式添加新的产品时就要编写一个新的产品类，同时还要引入抽象层，这必然会导致类结构的复杂化，所以，在某些情况比较简单时，是否要使用工厂模式，需要设计者权衡利弊了。