下面我们聊一聊
工厂模式实现的是创建者和调用者的分离。
工厂模式可以细分为，简单工厂模式、工厂方法模式、抽象工厂模式。
下面我们一一展开。
哦对了，开始之前，我们先了解一下设计模式的原则。
- OCP(开闭原则open-close principle)一个软件的实体应该对扩展开放，对修改关闭。说白了就是新增需求时，可以增加类，但是不要修改原有类。
- DIP(依赖倒转原则，dependence inversion principle)，针对接口编程，不要对实现类编程。
- LOD(迪米特法则，law of demeter)只与你直接的朋友通信，避免和陌生人通信。也就是不太相关的类不要有依赖组合。
好了我们回来讲我们的工厂模式。
工厂模式的核心思想就是实例化对象交给工厂来做，工程替我们new对象。从而使我们的调用者和实现类解耦。
- 简单工厂 用来生产同一等级结构中的任意产品（对新增的产品需要修改已有的类代码）
- 工厂方法 用来生产同一等级结构中的固定产品。（支持增加任意产品）
- 抽象工厂 用来生产不同产品族的全部产品。（针对增加新的产品，无能为力；支持增加产品族）
一般我们工作中用简单工厂的场景多一些。工厂方法会多出特别多的类，抽象工厂对于产品定义特别清晰的时候适用。
不使用简单工厂时
| 1 2 3 4 5 6 7 8 | public class Client01 { //调用者 public static void main(String[] args) { Car c1 = new Audi(); Car c2 = new Byd(); c1.run(); c2.run(); } } |
简单工厂
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | public class CarFactory { public static Car createCar(String type){ Car c = null; if("奥迪".equals(type)){ c = new Audi(); }else if("奔驰".equals(type)){ c = new Benz(); } return c; } } public class CarFactory { public static Car createAudi(){ return new Audi(); } public static Car createBenz(){ return new Benz(); } } |
工厂方法
抽象工厂
简单工厂和抽象工厂PK
- 结构复杂度 从这个角度比较，显然简单模式要占优。简单工厂模式只需要一个工厂类，二工厂方法模式的工厂类随着产品类个数增加而增加，这无疑会使类的个数越来越多，从而增加结构的复制程度。
- 代码复杂度 代码复杂度和结构复杂度是一对矛盾，既然简单模式在结构方面相对简洁，那么它在代码方面肯定比工厂方法模式复杂了。简单工厂的类随着产品类的增加需要增加很多方法，而工厂方法模式每个具体工厂类只完成单一的任务，代码简洁。
- 客户端变成难度 工厂方法模式虽然在工厂类上引入了接口从而满足OCP,但是在客户端中需要对工厂类进行实例化。而简单工厂模式的工厂类是静态类，在客户端无需实例化，这无疑是一个吸引人的优点。
- 管理上的难度 这是个关键的问题。 我们先谈扩展。总所周知，工厂方法模式完全满足OCP，及它有良好的扩展性。那是否就说明了简单工厂模式就没有扩展性了呢？答案是否定的。简单工厂同样具有良好的扩展性-扩展的的时候仅需要修改少量的代码（修改工厂类的代码）就可以满足扩展性的要求。尽管这没有完全满足OCP的要求，但我们不要太拘泥于设计理论，要知道，sun提供的java官方工具包中也要很多没有满足OCP的例子。 然后我们从维护性的角度分析下，假如某个产品类需要进行一定的修改，很可能需要修改对应的工厂类。当同时需要修改多个产品的时候，对工厂类的修改会变的特别的麻烦（对号入座已经是个问题了）。反而简单工厂没有这些麻烦，当多个产品类需要修改的时候，简单工厂仍然只需要修改一个工厂类（无论怎么样都能改到满足需求，大不了把这个类重写）。 所以和我们上面提到的工作中，我们一般都会使用简单工厂模式不谋而合。
抽象工厂相对复杂一些，这里就不展开了，JDK中使用到抽象工厂的地方
– JDK中Calendar的getInstance方法 – JDBC中Connection对象的获取 – Hibernate中SessionFactory创建Session – spring中IOC容器创建管理bean对象 – XML解析时的DocumentBuilderFactory创建解析器对象 – 反射中Class对象的newInstance()一般工厂模式的的类都会望文生义，都会带上factory