我眼中的所谓工厂模式

　　说起软件架构中的设计模式，大多数人肯定第一句就是，工厂模式。准确讲经典24个设计模式中没有工厂模式，而是简单工厂模式，工厂方法模式和抽象工厂模式这三种，三种互相有本质区别，各自为解决不同领域的问题，而形成的一套代码体系。我记得我毕业后第一份工作跳槽的时候，遇到的一次面试就有设计模式题目，不过当时太嫩，大败而归，也是那时知道有设计模式这个东东，因为这个学校是不教的。从此也就对设计模式就开始去研究啦，于是就有了这个系列的文章。

　　面向对象编程的三大基本特性：封装、继承、多态。简简单单的概念，其实每一个特性都能拓展得很深很深。这里我们只看下多态，多态就是利用了继承的概念，抽象依赖实现，可以看一个大家在学习编程语言启蒙的时候都会遇到的一个实例，首先创建一个基类，用接口也可以，里面放一个方法。

　　创建SampleBase类，代码如下：

public class SampleBase {

    public String getName()
    {
        return this.getClass().toString();
    }
}

　　再创建一个集成该类的衍生类，代码如下：

public class SampleImpl extends SampleBase {
    @Override
    public String getName()
    {
        return this.getClass().toString();
    }
}

　　在测试类中进行测试，测试代码如下：

public static void main(String[] args) {
        
    SampleBase base = new SampleImpl();
    System.out.println(base.getName());
}

　　运行结果：

class com.aspnetdream.test.SampleImpl

　　

其实对于这个情况，我脑海中一直记得一句话，基类指针指向子类应用，我的学习生涯接触这个最开始是在C++的语言中学习的，记住这句话，应对继承和多态我觉得是万能的法宝。基于编程语言这么一个优秀的特质，再想想在工作中遇到的很多应用场景，我曾经开发一个餐饮的ERP系统，在处理订单的时候，很多不同的单据，这些单据有相通之处，也会有各自不同点，比如配料订单和退货订单，这两种订单，相同的地方是对业务单据的物料拆分处理是一样的，但最后订单存储的表是不一样的，也就是说，两个单据我在拆分处理需要一样的代码，但在这一步完成之后，又各自走向不同的代码，好，套用简单工厂模式来解决。

创建单据基类IOrderInfo，我在这里把他定义成了一个接口，实际应用中可以定义为抽象类，甚至就是一个类。
创建IOrderInfo 接口，代码如下：

//简单工厂模式接口定义层
public interface IOrderInfo {
    public String getOrderInfo();
}

窗建完接口，我们分别创建配料单和退货单的衍生类。
配料单类OrderMakeCustom，代码如下：

//简单工程接口实现层   消耗订单操作类
public class OrderMakeCustom implements IOrderInfo {
    
    public String getOrderInfo()
    {
        return this.getClass().toString();
    }

}

退货单类 OrderReturnCustom，代码如下：

//简单工厂接口实现层  退货订单操作类
public class OrderReturnCustom implements IOrderInfo {
    
    public String getOrderInfo()
    {
        return this.getClass().toString();
    }

}

两个衍生类都实现IOrderInfo接口，写到这里稍微有经验点的同学就可以看出来，在实际代码调用中就可以

IOrderInfo order = new OrderMakeCustom();

不错可以这么做，这是比较粗暴的做法，但现实在项目开发的时候，这样的代码却比比皆是。
我们这里使用简单工厂来实现，把new的任务交给工厂来完成，将new的任务交给工厂而不是在具体的业务流程代码中去完成，我个人任务有一下几点好处：
1、代码的整洁度，易于维护，如果整篇代码掺杂很多的new，我想读代码的人是相当痛苦的，这种流线型的代码方式，带来的恶果就是，业务一复杂，大家就开始走迷宫。
2、将代码放入工厂中，可以为后续代码升级做准备，如果，我将对应的接口实现的所有子类对应的放入一个xml文件中，用反射来实例化一个具体的基类的，这是不是就是IOC的原型啦。

继续代码，创建一个Factory，在这个类中就是根据不同业务流程，创建不同订单实例交给调用方，实现代码：

public class Factory {

    //简单工厂模式   创建实现操作类工厂
    public static IOrderInfo createOrderInfo(EServiceType createType)
    {
        switch(createType)
        {
            case Make:
                return new OrderMakeCustom();
            case Return:
                return new OrderReturnCustom();
            default:
                return null;
            
        }
    }
}

为了便于创建我这里放了一个枚举类型，简单工厂的工厂类根据传入的不同枚举类型，闯将不同的实例类。

OK，到这里一个简单工厂模式就搭建完成了，我们来测试运行，测试代码如下：

public static void main(String[] args) {
        
        SampleBase base = new SampleImpl();
        System.out.println(base.getName());
        
        //根据不同的类型实例化不同的订单操作类
        //------简单工厂模式（静态工厂模式）
        //退货订单操作类
        IOrderInfo order = Factory.createOrderInfo(EServiceType.Return);
        //获取订单后，处理订单
        getOrderInfo(order);
        
        order = Factory.createOrderInfo(EServiceType.Make);
        getOrderInfo(order);

    }

    //实际项目中对订单模型进行操作，而不用关注是那种类型订单，在业务实现层去关注返回什么样的订单
    private static void getOrderInfo(IOrderInfo order)
    {
        System.out.println(order.getOrderInfo());
    }

运行结果：

class com.aspnetdream.bussinessImpl.OrderReturnCustom
class com.aspnetdream.bussinessImpl.OrderMakeCustom

使用抽象层IOrderInfo对象作为句柄，具体实现看不同的业务要求去工厂请求相应的实现层。再回到我最开始描述的场景，对两种单据中相同的业务我们可以放入抽象层，甚至在抽象层我们可以定义不同的业务代码相同的调用方法，这样你的代码档次就会被拉高很多很多！简单工厂模式也叫静态工厂模式，它创建实现层的方式较为呆板，只是把new的代码都放入了工厂中，但你依然需要使用选择模式，也就是告诉工厂你是创建A，还是创建B，这就是我代码中加入枚举的原因了，这其实在代码本质上和new 一个具体实现没有太大的区别。所以，由此就产生了工厂方法模式。对于这个模式的应用在我的印象中是基于不同的产品操作而想到的，在开发一个POS后端应用时，都是产品信息，但是交给POS端和交给手机移动端的信息是不一样的，POS端也许信息比较全面，交给移动端信息比较少，因为在我这个产品中，移动端仅限于看报表。这里我们尝试着用工厂方法模式来解决这个问题。
首先创建产品的基类，iproduct接口，代码如下：

//工厂方法模式---抽象角色接口
public interface iproduct {

    public String getPrdName();
}

再分别创建Pos和移动端不同的产品实现类，PosProduct和MobileProduct类，代码实现：

//工厂方法模式 具体角色类
public class MobileProduct implements iproduct {
 
    //实现抽象角色接口
    @Override
    public String getPrdName()
    {
        return this.getClass().toString();
    }
}

//工厂方法模式---具体角色类
public class PosProduct implements iproduct {

    @Override
    public String getPrdName()
    {
        return this.getClass().toString();
    }
}

基于应用角色我们就创建完了，使用工厂模式，肯定需要创建工厂嘛，创建产品抽象工厂IProductFactory，代码如下：

//工厂方法模式 ---- 抽象工厂
public abstract class IProductFactory   {

    public abstract iproduct getProduct();
}

抽象工厂负责返回抽象角色，抽象对抽象。

有抽象就有实现，我们需要操作POS和Mobile端不同的产品信息，如是，针对抽象我们有2个不同业务实现要求，那么实现抽象来创建这2个实现工厂PosFactory和MobileFactory，代码如下：

//工厂方法模式 ----具体角色工厂 pos产品工厂
public class PosFactory extends IProductFactory {
    
    public iproduct getProduct()
    {
        return new PosProduct();
    }

}


//工厂方法模式---工厂方法模式 具体产品共  移动类产品工厂类
public class MobileFactory extends IProductFactory  {

    public iproduct getProduct()
    {
        return new MobileProduct();
    }
    
}

创建完这一步其实基本的工厂方法模式也就完成了，接下来我们测试，测试代码如下：

public static void main(String[] args) {
    
        //------工厂方法模式
        IProductFactory ifactory = new MobileFactory();//移动端类产品工厂     返回移动端产品
        iproduct prd= ifactory.getProduct();
        System.out.println(prd.getPrdName());
        
        ifactory = new PosFactory();//返回pos类产品工厂  返回pos类产品
        prd = ifactory.getProduct();
        System.out.println(prd.getPrdName());
        
    }

    //实际项目中对订单模型进行操作，而不用关注是那种类型订单，在业务实现层去关注返回什么样的订单
    private static void getOrderInfo(IOrderInfo order)
    {
        System.out.println(order.getOrderInfo());
    }

运行结果：

class com.aspnetdream.driver.productImpl.MobileProduct
class com.aspnetdream.driver.productImpl.PosProduct

工厂方法模式，在我的记忆中就是抽象对抽象，实现对实现，实现多少依据具体的业务需求来完成，可以无限的实现下去，当然，你就需要无限的工厂来帮你实现。

　　简单工厂模式和工厂方法模式比较分析：
　　在我看来，简单工厂模式就是工厂模式中的屌丝，工厂方法模式就是高富帅，屌丝的最大特点就是，“躲进小楼成一统，管他春夏与秋冬”，外部怎么弄的我不管，你给让我创建什么类型，我创建好给你就行，同时你也必须将需要创建的类型写入工厂中，也就是new一个实例。
然而，高富帅的工厂方法模式，有娘生也有娘养，首先在工厂的抽象层，你就必须要对应你这个工厂操作的对应的角色类型，也就是说你一出生属于哪个帮派的已经基本确定了，所以一般都会对角色进行抽象，在工厂抽象层操作的类型肯定也是抽象，“抽象对抽象”---又说了一遍。
基于上面的表述，简单工厂模式路子很野，你想创建啥我就创建啥，随便来，这和直线的代码比起来其实差别不大。工厂方法模式一脉相承，代码比简单工厂模式要复杂，但是无形中确规范了不少，依据这样的模式，代码分层其实就特别顺溜。

　　好了，对应于工厂模式我刚才说了，你想实现多少就实现多少，这是好处，也是坏处，代码总归是有限的，需求泛滥，也总过就人死灯灭的时候，正是由于实现终归是有限的，所以在实现的时候，如果能不要这么多实现工厂是不是代码就稍微简洁点呢。由此，我们就产生了抽象工厂模式，将原先在工厂方法模式中，实现工厂的代码移到一个统一的抽象层中，再来针对抽象进行实现，看看代码怎么实现。
创建抽象工厂模式的抽象工厂类AbstractFactory，代码如下：

//抽象工厂模式--抽象工厂
public abstract class AbstractFactory {

    public abstract iproduct createPosProdct(); 
    
    public abstract iproduct createMobileProduct();
}

针对抽象类的实现层DefaultFactroy，代码如下：

//抽象工厂模式的工厂实现层
public class DefaultFactory extends AbstractFactory{

    public iproduct createPosProdct()
    {
        return new PosProduct();
    }
    
    public  iproduct createMobileProduct()
    {
        return new MobileProduct();
    }
}

好，抽象工厂就塑造好了，下面测试，测试代码如下：

    public static void main(String[] args) {
    
        ///---抽象工厂模式
        AbstractFactory dfactory = new DefaultFactory();
        prd = dfactory.createMobileProduct();
        System.out.println(prd.getPrdName());
        
        prd = dfactory.createPosProdct();
        System.out.println(prd.getPrdName());
    }

运行结果：

class com.aspnetdream.driver.productImpl.MobileProduct
class com.aspnetdream.driver.productImpl.PosProduct

抽象工厂和工厂方法模式我觉得没有谁好谁坏，不同的应用场景使用不同的模式，在我们现实的工作场景中，处理一个问题，往往是几种模式一起用，某个应用模式的内部代码或许有其他的模式来实现。二十四种设计模式，其实每一个割裂开来看，每个都很简单，上面的代码相信每一个人都能看的懂，但，如何去用就是基本功的问题，代码灵活地拓展和应用也同样是对自身代码能力的一个要求。
好了，就此搁笔，算是抛砖引玉，欢迎拍砖指教！

我的目录结构：

最后贴上我的源代码：http://files.cnblogs.com/aspnetdream/factory.rar