定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
工厂方法模式能够封装具体类型的实例化。看看下面的类图，抽象的Creator提供了一个创建对象的方法的接口，也成为“工厂方法”。在抽象的Creator中，任何其他实现的方法，都可能使用的这个工厂方法所制造出来的产品，但只有子类真正实现这个工厂方法并创建产品。
如同定义中所说的，常常听到其他开发人员说:工厂方法让子类决定要实例化的类是哪一个，希望不要理解错误，所谓的“决定”，并不是指模式允许子类本身在运行时做决定，而是指在编写创建者类时，不需要知道实际创建的产品是哪一个，选择使用了哪个子类，自然就知道了实际创建的产品是什么。
1.png
创建者类
创建者类.png
具体代码
/**
* 工厂方法
*/
public abstract class PizzaStore {
public Pizza orderPizza(String type){
Pizza pizza = createPizza(type);
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza;
}
abstract Pizza createPizza(String type);
}
产品类
产品类.png
代码
/**
* Pizza 抽象类，所有的Pizza都来自这个派生类
*/
@Data
public abstract class Pizza {
/**
* 每个pizza都有的特性
*/
String name;
String dough;
String sauce;
ArrayList toppings = new ArrayList();
/**
* 抽象类提供了基本的做法
*/
public void prepare(){
// code
}
public void bake(){ }
void cut(){ }
public void box(){ }
}
所谓的平行类层级
我们已经看到，将一个orderPizza方法和一个工厂方法联合起来，就可以成为一个框架。除此之外，工厂方法将生产知识封装进各个创建者，这样的做法，也可以视为是一个框架
平行类.png
看看对象依赖
当你实例化一个对象时，就是依赖它的具体类。本文中的例子，它有比萨店类来创建所有的披萨对象，而不是委托给工厂。如果把他看成一张图，看起来是这样的
对象依赖.png
依赖倒置原则
很清楚的，代码里减少对于具体类的依赖是一件好事。事实上，有个OO设计原则就是正式阐明了这一点；这个原则我们成为："依赖倒置原则"（Dependency Inversion Principle)。通则如下：
要依赖抽象而不是具体类
首先，这个原则听起来像是”针对接口编程，不针对实现编程|”，不过这里更偏向于“抽象”。这个原则说明了不能让高层组件依赖底层组件，而且，不管高底层或底层组件，两者都应该依赖于抽象。
这个听起来很玄学。
我们看看前面的对象依赖图，PizzsStore是高层组件，而披萨实现是底层组件，很清楚的，PizzaStore依赖这些具体披萨类。
现在这个原则告诉我们，应该重写代码以便于我们依赖抽象类，而不是依赖具体实现类。对于高底层模块都应该如此。
接下来我们改造一下上面的例子，来实现这个原则。
网友评论