浅谈Spring框架经典模式之工厂模式(二)工厂方法模式

    hello艾瑞巴得，我还是那位可爱的萌新。这次本篇文章发表的是本人对工厂模式中工厂方法模式的一些浅显的看法，还是很希望各位大神可以对这些不成熟的看法表达自己的观点~~来者不拒~~~~

        好了，接下来正题来了，当当当~工厂方法模式闪亮登场。工厂方法模式说白了其实就是简单工厂方法模式的一种升级或者说是进一步抽象，它可以应用于更加复杂的场景。灵活性更高。因为每一个工厂都只对应一个相应的对象。这样也就不存在不遵守ocp原则这种现象了。新增无数的对象，那就扩展更多的工厂就好了。好了，废话不多说，直接上一个简单的小demo来简单描述一下。

    司机工厂由于每天业务太多，决定在多个地区建立分工厂，把自己的所有下属职能全部分配到各个下属工厂，并且派一个人来专门负责这个工厂。但司机工厂也怕分工厂以后不听它的指挥，所以就把自己的核心技术留下，下属工厂需要来借：

public abstract class AbstractDriverFactory {
	//这个方法是为了它的子类重写它的构造方法
	public abstract Animal createDriver();
}

    好了，接下来，有请工厂代表老张闪亮登场~~~~让他带我们去看看他的工厂~~~

    

public class ZhangFactory extends AbstractDriverFactory {

	@Override
	public Driver createDriver() {
		//返回一个具体的对象老张。
		return new Zhang();
	}

}

    从代码中我们可以看出，老张工厂只负责创建姓张的司机这一个职能。并且要借(继承)司机工厂里面的方法来重写。这样每个工厂负责的事物量就会很低，效率相对更高：

    

public static void main(String[] args) {
		//创建老张的工厂对象
	ZhangFactory zf = new ZhangFactory();
	//再调用创建司机的方法
	Driver driver = zf.createDriver();
	//司机去开车
	driver.driveCar();
	}

    不得不说，工厂方法模式虽然完美符合了ocp原则，但却使整个程序变得很沉重。就拿数据库来说，如果有100个访问数据库的类，那么就要创建100个这个类的工厂。

    最后简单总结一下： 

    等等！！在总结之前，我想先说明一下为什么没有提起抽象工厂模式，在我本人理解中，抽象工厂模式无非是对工厂模式的抽象方法再做一层抽象，让抽象的工厂实例化。两者之间并没有清晰明了的分界线。现在大多数情况下还是使用工厂方法模式比较好，个人感觉~~~

    首先对这三种工厂模式做一下简单的对比和区分：

    1.简单工厂模式：最大的优点就是在工厂中就包含了必要的判断，使用时只需要根据客户端的选择来实例化即可，对于客户端使用来说，去除了与具体产品的依赖。而缺点就是违背的ocp原则。假如未来要添加一个新的需求，则需要更改简单工厂中的判断语句。这对代码本身就不利。

    2.工厂方法模式：最大的优点就是抽象化了简单工厂模式。再有新的需求进来时，不需要更改工厂的内容，符合了ocp原则。而缺点是每增加一个产品就要新增加一个相应的实例化工厂，增加了额外的开发量。

    3.抽象工厂模式：分离了具体的类。不会出现在客户端代码中，易于交换产品系列。而且具体的工厂类只在它初始化的时候才会出现。这使得改变一个应用的具体工厂变得很容易~~缺点是，抽象工厂几乎确定了可以创建的对象的集合。加入新的类型对象就需要扩展其接口，这将涉及到具体工厂及其子类的修改。

    三种工厂模式虽然用法各不相同，但它们的最终目的都是一致的----解耦。而且在使用的时候，我认为真的没有必要去认真的划分它们的界限。因为可能明明一开始使用的是工厂方法模式，但后来加入了新的需求后，可能需求关系发生改变，最后完成了才发现这竟然是抽象工厂的模式。而究竟应该使用哪种模式，其实还是应该看需求而定吧。最后祝各位同仁们可以事业步步高升~~~~做大牛，走向人生巅峰。