怕是时间一久又搞混了简单工厂模式、工厂方法模式和抽象工厂模式，还是输出一下吧。这几种模式说简单，倒是真的不难，就是自己怎么运用到平日项目中去，这点让我很是头疼 。这篇文章我不会很细致地代码UML图相结合来介绍这几种模式，如果是小白，可以看这位四月葡萄
写的Android的设计模式，可以说是很友好全面了，今天我主要就啰嗦两句我觉得重要的点，以便以后一看就记起。
（一）简单工厂模式
优点是代码解耦，创建实例的工作与使用实例的工作分开，使用者不必关心类对象如何创建。
简单工厂模式有一个最大的问题——如果现在接口的子类增加了，那么工厂类肯定需要修改，这样违反了开闭原则（OCP）。因此可以使用反射来创建实例对象。
packagecn.mldn.demo;
interface Fruit {
public void eat() ;
}
class Apple implements Fruit {
public void eat() {
System.out.println("吃苹果。");
};
}
class Orange implements Fruit {
public void eat() {
System.out.println("吃橘子。");
};
}
class Factory {
public static <T extends Fruit> T create(Class<T> clz) {
Fruit f = null;
try{
//看这儿看这儿~反射出实例
f = (Fruit) Class.forName(clz.getName()).newInstance() ;
} catch(Exception e) {
e.printStackTrace();
}
return (T)f ;
}
}
public class FactoryDemo {
public static void main(String[] args) {
//调用方式
Factory.create(Orange.class).eat();
Factory.create(Apple.class).eat();
}
}
利用反射后即使增加了接口的子类，工厂类照样可以完成对象的实例化操作，这个才是真正的工厂类，可以应对于所有的变化。但用反射的话，性能是一个问题，反射相当于一系列解释操作，通知jvm要做的事情，性能比直接的java代码要慢很多。且不安全，通过反射机制我们能拿到类的私有成员。
以前我对简单工厂模式很有偏见，因为觉得它违反开闭原则的缺点实在是太明显了。而在实际项目中我也会写出缺点很明显的代码，很气，但就是不知道怎么改进。或许我之前这么鄙视简单工厂模式，其实是在鄙视写臭臭代码的自己呀。只能多学习多思考了。而且简单工厂模式确实是有其优点之处的呀，创建实例的工作与使用实例的工作分开~
参考：Java的反射机制
（二）工厂方法模式
没什么值得说的，拷贝一个UML图出来好了。工厂方法模式每个工厂只能创建一种类型的产品。
（三）抽象工厂模式
其实大家看看这图，很容易可以看出来如果增加新的产品,抽象工厂模式需要修改抽象工厂和所有的具体工厂,也违反了开闭原则。这就是抽象工厂模式的缺点了。
对比一下工厂方法模式和抽象工厂模式——
在工厂方法模式中具体工厂负责生产具体的产品，每一个具体工厂对应一种具体产品，工厂方法具有唯一性。抽象工厂模式则可以能够创建多种类型的产品，应用场景为生产多个产品组合的对象。抽象工厂模式代码解耦，创建实例的工作与使用实例的工作分开，使用者不必关心类对象如何创建。
温故知新。工厂模式的初衷是解耦解耦解耦，创建实例的工作与使用实例的工作分开，使用者不必关心类对象如何创建。
