设计模式——简单工厂模式（Simple Factory）

“针对接口编程，而不是针对现实编程”这个原则带给了我们许多的好处，例如：

public void doSomething(Animal animal) {
    ...
}

这里的Animal是一个接口，那么doSomething方法内部根本不需要管animal这个引用到底调用的是哪个对象，因为Animal可以有各种各样的实现类

但是看看这段代码：

Animal animal = new Dog();

这样有什么问题呢？虽然下面的代码依然是使用了Animal的接口来进行编程，但是在创建对象这个地方，我们还是在代码中显示地指定了具体的实现类是Dog

如果编程的场景足够糟糕的话，甚至还会出现这样的代码：

Animal animal = null;
if (DOG.equals(xxx.getType())) {
    animal = new Dog();
} else if (CAT.equals(xxx.getType())) {
    animal = new Cat();
} else if (TIGER.equals(xxx.getType())) {
    animal = new Tiger();
} ...
...
...

一旦Animal的实现类的种类发生了变化，我们就不得不修改现有的代码了

而为了让"产生对象"这个行为也可以和具体的实现类隔离开来，于是就有了工厂模式：

Animal animal = AnimalFactory.create(xxx.getType());

而具体生成什么样的对象，怎么样去生成一个对象，这些就是AnimalFactory的事情了，我们业务逻辑代码中根本不需要去关心这些

可能还会有疑问，生成对象的代码在AnimalFactory写和在业务逻辑中去写不是都一样吗？不是都要写一次吗？

但要记住，生成Animal对象的场景可能并不是只有一个，可能有几个，甚至几十个地方都需要根据相同的规则去生成一个Animal对象

这样AnimalFactory的价值就真正体现出来了