工厂方法模式--《HeadFirst设计模式》

工厂方法模式可能是我们在实际开发过程中，经常能使用到而且也可能是听过最多的一个设计模式，但是对于工厂方法模式的理解、工厂方法模式到底应该如何使用以及工厂方法模式有哪几种，今天将带给大家揭晓；

工程方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

工厂方法

通过上图来仔细分析下这个模式：

Creator是一个类，它实现了所有操纵产品的方法，但不实现工厂方法(factoryMethod),Creator所有的子类都必须实现这个抽象的factoryMethod()方法。

ConcreteCreator实现了factoryMethod(),以实际生产出产品。同时ConcreteCreator负责创建一个或多个具体产品，只有ConcreteCreator类知道如何创建这些产品

所有的产品必须实现Product这个共同的接口，这样一来，使用这些产品的类就可以引用这个接口，而不是具体类。

通过上面的分析，可知抽象的Creator提供了一个创建对象的方法的接口，也称为“工厂方法”，在抽象的Creator中，任何其他实现的方法，都可能使用到这个工厂方法创建出来的产品，但只有子类真正实现这个工厂方法并创建产品。

工厂方法让子类决定要实例化的类是哪一个。所谓的“决定”，并不是指模式允许子类本身在运行时做决定，而是指在编写创建者类时，不需要知道实际的产品时哪一个。选择了使用那个类，自然就决定了实际创建的产品是什么

通过一个Pizza的例子来具体的理解下，具体类图如下：

类图

工厂方法具体实现代码(点击下载)

通过上面的demo更能够体会到工厂方法的优点。当增加商店或者改变产品的时候，Creator并不会受到影响，真正的做到了解耦。（因为Creator与任何的ConcreteProduct之间都不是紧耦合）。demo中使用了类型参数，这样似乎有点不妥，可能造成运行时错误(比如type类型拼写错了)，在时间的开发中，可以创建代表参数类型的对象和使用静态常量或者enum

依赖倒置原则

代码中减少对于具体类的依赖是件“好事”，事实上有一个OO设计原则就正式阐明了这一点；这个原则即：依赖倒置原则 Dependency Inversion Principle

设计原则：要依赖抽象，不要依赖具体类

这个原则说明了：不能让高层组件依赖低层组件，而且不管高层或低层组件，“两者”都应该依赖于抽象。

在上面PizzaStore的例子中，PizzaStore就是“高层组件”，而披萨实现是“低层组件”；在应用工程方法之后，高层组件(PizzaStore)和低层组件(具体Pizza类)都依赖了Pizza抽象。想要遵循依赖倒置原则，工厂方法并非是唯一的技巧，但却是最有威力的技巧之一。

几个指导方针可以帮助遵循依赖倒置原则：

1、变量不可以持有具体类的引用(如果用new就会持有具体类的引用，可以用工厂方法来避开这样的做法)

2、不要让类派生自具体类(如果派生自具体类，就会依赖具体类。请派生自一个抽象)

3、不要覆盖基类中已实现的方法(如果覆盖积累已实现的方法，那么基类就不是一个真正适合被继承的抽象。基类中已实现的方法，应该由所有的子类共享)

总而言之是要倒置思考的方式，倒置指的是和OO设计的思考方式完全相反。低层组件依赖高层的抽象，同样的，高层组件也依赖相同的抽象。

除了工厂方法模式外，还有抽象工厂方法模式；下一篇文章将深入分析抽象工厂方法模式，并且对比工厂方法模式，对工厂方法模式将会有更深入的了解

抽象工厂模式

总结：

OO基础：

封装、继承、多态、抽象

OO原则：

封装变化

多用组合，少用继承

针对接口编程，不针对实现编程

为交互对象之间的松耦合设计而努力

对扩展开放，对修改关闭 --- 开闭原则

依赖抽象，不要依赖具体 --- 依赖倒置原则