今天重新学习了下工厂模式：简单工厂模式、工厂方法模式、抽象工厂模式，总结下。
首先，从名字上看，三个模式都有”工厂“二字，工厂，自然是生产产品的，工厂模式就是生产类的实例的，而具体生产哪种实例，怎样生产，何时生产，这就是三种工程工厂的区别，以下先分开阐述：
①，简单工厂模式
之所以简单，我觉得在于它就一个工厂，就实现了生产实例的功能(相对于另外两种工厂模式的多个工厂，确实简单很多)，具体实现中，只需要告诉该工厂要生产哪种材料（实例），它就会准确的把相应实例产出给你，用起来是很简单，但维护起来可就麻烦些了，因为选择逻辑是在工厂中实现的，依《大话设计模式》中的例子来说，生产加减乘除哪种子类实例，工厂类里会通过switch..case来实现，可想而知，当新添子类(比如开平方根、开立方根等)，除了要添加运算子类外，工厂中的switch..case逻辑也要改动，显然这是违背了开放封闭原则的,稍不注意，可能会修改出错而影响程序正确执行。可以说，简单工厂模式有优势(使用简单)，也有弊端（维护困难，容易出错），正因为如此，演化出了工厂方法模式：
②，工厂方法模式
相对于简单工厂模式，工厂方法是做了进一步的抽象---对简单工厂模式中的工厂。有变化就应该有抽象吗，既然新增算法(比如开平方根、开立方根等)会修改工厂，那我们就应该对这个变化点做进一步的抽象，抽象出IFactory，让继承它的子工厂决定实例化那一个子类（AddFactory生产new AddClass()....）,这样很好的解决了简单工厂模式修改工厂容易出错的弊端：压根不用修改任何类，只是单纯的扩展，添加开平方根运算，就加开平方根运算子类，加开平方根运算工厂，没有修改，只有扩展，遵循了开放封闭原则，这些是优点，缺点呢，就是扩展时需要添加多个子类，稍有啰嗦，不过可以忽略了，架构清楚的话，多添几个类，一劳永逸
③，抽象工厂模式
抽象工厂模式算是基于工厂方法模式吧，就书中的例子已很好的说明问题：多个业务表（用户表、部门表），多数据源操作(sqlserver,access,oracle),就衍生出了更普遍的工厂使用方式：IFactory(工厂基类)定义要操作的业务对象：IUser,IDepartment,子类就实现它，定义具体操作种类(SqlserverFactory:返回sqlserver中对user,department操作的对象..)基本就是工厂方法模式业务的普通化或说复杂化吧，不上代码了，书中都有的（别说没有书啊，《大话设计模式》起码要有吧，个人感觉算是设计模式的启蒙读物了）。
总结：简单工厂，到工厂方法，再到抽象工厂，最后发现抽象工厂过于复杂(还拿书中例子来说，扩展一个业务表(如project)的话，要新增几个类、修改几个工厂)，够繁琐，倒不如简单工厂来的直接，一个工厂全部搞定，当然，还可以使用反射、配置文件结合的方式来决定实例化的类，这就要我们在实际用的时候去权衡了，不要一味的遵循某个模式，每个模式都有利有弊，切不可过于教条，只要尽量贴近六大设计原则，合理变通(如之前提到的抽象工厂结合简单工厂，或者用反射、配置文件等)，都能更好的优化我们的程序，使代码更优雅简洁，慢慢摸索吧
算是对工厂模式的简单总结--基于思想层面吧，希望能引起读者的思考