工厂模式初步了解

工厂模式是设计模式中最常用，而简单工厂模式，是最简单的模式了。回想我们最开始学习JAVA时候，学完运算符、变量、循环等基本的语法知识后，就开始学类对象的各种知识。类是一个单独的对象，一个单独的类只能起到简单的作用，而类被组织起来，形成复杂的依赖关系后，就能形成一个庞大的系统，为各种场景服务。

简单工厂模式场景演示

在一个类对象中，引入其它类，实例化后依赖其他类，是一种最常见的过程。而在这常见的过程中，前辈们发现一个问题：在实际的业务场景中，有些时候我们需要根据场景的不同，去实例化功能相同，却又有差异化的对象。按照普通的过程，我们会在需要的过程中，去直接实例化这个对象。比如你自己现在买有2双鞋子，一双阿迪，一双耐克，那么为了表示你有2双鞋子，就需要给你直接实例化2个对象。

//你说你是鞋子，那就得我允许才行
public interface Shoes();
//阿迪白饭鱼
public class Adidas implements Shoes{};
//NIKE无敌
public class Nike implements Shoes{};
//我的小仓库
public class Store(){
    //我的鞋子在这里哟
    List<Shoes> myShoes = new ArrayList();
    //我有白饭鱼又无敌
    public void myShoes(){
        Shoes ad= new Adidas();
        //我有一双白饭鱼啦
        myShoes.add(ad);
        Shoes nike = new Nike();
        //我有一双无敌啦
 		myShoes.add(nike);
    } 
}

为了表明你有2双鞋子，在代码的过程中，就得通过new Adidas()和new Nike()，来实例化2个鞋子对象给你。这个过程中，仔细看，你是不是发现了，虽然你new的对象是Adidas和Nike，但你声明的对象都是Shoes，也就是new这个过程实际是重复的。伟大的哲学家四人帮告诉我们，重复的行为是可以被取代的。现在手工作坊的形式就要被简单工厂模式取代了。

//还是我拉，鞋子界的统帅
public interface Shoes();
//还是我拉，白饭鱼
public class Adidas implements Shoes{};
//还是我拉，无敌
public class Nike implements Shoes{};
//小作坊，你能一天生产1万双鞋子吗，专业的事情还是让我这工厂来吧
public class ShoesFactory(String shoeType){
    public Shoes getShoes(){
        if(shoeType.equals("adidas")){
            return new Adidas();
        }else if(shoeType.equals("nike")){
            return new Nike();
        }else{
            throw new UnknowShoeType();
        }  
    } 
};
//我的小仓库
public class Store(){
    //我的鞋子在这里哟
    List<Shoes> myShoes = new ArrayList();
    //我有白饭鱼又无敌
    public void myShoes(){
        Shoes ad= ShoesFactory.getShoes("adidas");
        //我有一双白饭鱼啦
        myShoes.add(ad);
        Shoes nike = ShoesFactory.getShoes("nike");
        //我有一双无敌啦
 		myShoes.add(nike);
    } 
}

看看，看看，之前小作坊生产的鞋子，被工厂替代了，你只要跟鞋子工厂ShoesFactory说你要什么鞋子，人家就会给你生产，而不是每次都要自己去生产一双鞋子。

简单工厂模式解决的问题

但是这里有个问题，我代码中直接new实例化和通过ShoesFactory获取实例对象有什么区别呢，为什么简单new就行的事情，要搞的那么复杂呢？

这里就涉及到设计模式产生的起源，设计模式是为了解决特定场景的解决方案，那么简单工厂模式解决的问题场景是什么呢？

从上面的代码过程看，简单工厂模式只是把实例化的过程隐藏起来，把选择实例化哪个实现类的选择权从代码过程中剥离，调用的时候只需要表明要什么，而不用关心怎么要。这样的话，简单工厂模式解决的问题场景其实就是实现类选择的问题，把依赖者和被依赖者，通过工厂这个中间对象，来隔离开。

如果在开发过程中，一个类的实例化过程很复杂，或者一个类在实际运行中有不同的场景选择，那么可以考虑使用简单工厂模式，来分离实例化逻辑。

但简单工厂模式有个问题，就是如果我要增加一个鞋子的品类，比如李宁，那么我除了得新创建一个LiNing的鞋子类外，我还得修改ShoesFactory中的创建逻辑，这样把新的鞋子种类包含进来。改一个还好，如果每天都有新的鞋子种类新增呢，难道都去改ShoesFactory这个类？这很明显违背了设计模式的一个原则：开闭原则。简单工厂模式对修改没有关闭，如果改动频繁，改着改着，就有可能会导致逻辑混乱，那么如果避免这个问题呢？那就得请出简单工厂模式的升级版：工厂模式了。