创建型—工厂模式

简述

工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。工厂模式具体的分为:简单工厂模式、工厂方法模式和抽象工厂模式。这三种模式一个比一个的抽象，在这要清楚的是，有时候我们也把简单工厂模式看成工厂方法模式的一种特例，在这里讲的是上一种分类。

简单工厂模式

具体产品角色

这个类就是产生对象的模板类。
方法（函数）和属性（数据）就是类的组成元素，当然，一个类可以只有其中的一类，这样类可以管理一些方法和属性，使编程的颗粒变的大了一些，也使其集中了些，使其对外的耦合性减低了。

抽象产品角色

这个类就是为了把同类类的对象组合在一起管理，使这些具体类由原来对外提供的多个接口现变成一个，继承，多态等等好处都具有了。

这个类的使用规范了一些类，这样这些类在具体编程的时候避免了很多不必要的错误，同时它使编程的颗粒变的更大了一些，使其对外的耦合性或者外对内的依赖没有了，方便扩展，复用高层等等。

工厂类角色

通俗点说就是产生具体对象的类。这个类里控制到底产生那个对象，所以，在工厂类里面涉及到逻辑判断的逻辑运算。
工厂类的是简单工厂模式的核心，这个类的出现使程序中的任务和功能更加的具有模块性，增强了复用、可维护和灵活性等等。

工厂方法模式

具体产品角色

同上

抽闲产品角色

同上

抽象工厂角色

从上面可知，简单工厂模式中的具体工厂类里面有逻辑判断运算，就是if或者switch语句，起初把这个从客户端类中分离出这个功能块（客户端类的还有其他的功能），一个目的是为了让其职责更加的明确，使程序在修改、维护和复用等方面表现的更好，这个对于逻辑判断少的时候应用这种模式非常的好，但是，如果这里面的逻辑判断运算非常的多，并且，以后要扩展的可能性非常的大，那么这种情况就不怎么好了，你（不是源程序编写者的维修人员）每次扩展的时候，都要去读懂里面的逻辑判断，由于逻辑判断非常的复杂，自己可能理解偏了，这样就增加了错误的发生率，针对这种逻辑判断多，并且，以后扩充的可能性非常的大的时候，我们就用先建立一个抽象工厂类，抽象工厂类和抽象产品类的作用几乎是一样的，他的作用就是把逻辑判断运算分解成相应的类，并且由抽象工厂类去管理，扩展功能的时候就是添加继承抽象工厂类的子类，然后再写出相应的具体工厂类。

具体工厂角色

上面的简单工厂模式中的工厂类里面有复杂的逻辑判断运算，通过这种逻辑运算查看符合那种情况，然后再在那种情况下写下产生具体产品的代码，而此时的具体工厂类就是写有产生具体某种产品的代码的类。

工厂方法模式和简单工厂模式的区别

工厂方法模式就是把简单工厂中的工厂类分成为抽象工厂类和具体工厂类。简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择的条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖；工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单的内部逻辑判断移动到了客户端代码来进行，你想要加功能，本来是改工厂类的，而现在是修改客户端。
简单工厂模式在扩充的时候，可以不需要修改客户端代码，只需要最终用户输入逻辑名称就可以了，但为什么有时候还要用工厂方法模式呢？这种模式的情况是简单工厂模式中的工厂类里面的逻辑判断运算太复杂了，并且，具体类扩展或易变性很大，这样的话，我们扩展等操作的时候还要看懂工厂类里的逻辑代码，这样时间上增加了，并且写出的代码也易错，但是，工厂方法不用修改业务逻辑上的代码，只需要扩充性就性，至于客户端改动的逻辑代码是很简单的。

抽象工厂模式

概述

我们写一个类，但是，根据我们对业务的理解，用户可能会在这改变自己的业务需求，也就是说，用户可能让我们把这个类改成其他同类的类，出于易变性等等方面的考虑，我们使用了简单工厂模式，但是，如果本身它的具体类就很多，而且，仍具有很大的易变性（扩充），这时我们采用工厂方法模式，这个模式只应用于一个整体的时候，但是，当有多个整体应用工厂方法模式时，并且这些整体有很强的关系时，我们采用抽象工厂模式，即把多个整体的抽象工厂和具体工厂类浓缩成一个整体的抽象工厂类和具体工厂类，然后这个应用于所有的其他的整体，这样的话好处多多。

简单工厂改进抽象工厂

通过上述描述和上图，我们可以清楚的知道，程序可以非常方便的对于以编写好的具体类进行转变，但是，如果我们扩充一个没有提前编写好的具体类的时候，就会非常的麻烦，例如：要增加相应的整体，并且需要对于抽象工厂类和具体工厂类进行修改，为了解决这种情况，我们用简单工厂来改进抽象工厂




应用这个方式，我们可以很容易的对于不存在的具体产品进行扩展，但是，在这里我们需要注意的是，此时的工厂类里面有相应的逻辑运算，即里面有switch或if语句，我们知道修改逻辑运算代码会给我很多的麻烦（读懂代码，修改易错等等），如果逻辑判读的少还好说，但是，如果多的时候，我们就要注意用另一种方式了，即：引入反射

引入反射

引入反射的UML图和上图大致一样只是类里的内容有些差别而已。反射就是一个功能的简称，这功能是什么呢？我们可以理解它是一个函数，我们给里填写相应的参数（具体的类的命名空间+类名），然后，当程序运行到这里的时候，程序就会运行参数指的那个类，这个就是反射的功能。我们理解反射后，就知道，我们可以把工厂类中的逻辑运算变成多个方法，每个方法内有相应的反射，这样就解决了这个问题。

反射中的参数，我们可以不用写死，可以通过变量的形式表示出来，这样我们可以修改变量（通过读取文件给变量赋值的方法改变）来达到需求的变动，这样修改的任务就小的多了，而且也安全的多了。

总结

　　这几种模式没有绝对的好，也没有绝对的不好，在不同的情况下，这几种模式中最好的模式也是不同的。

　　工厂模式就是在具体类（实体类）和客户端建立了一个缓冲，根据这个缓冲区内部结构可以分为更加具体的工厂模式。