简单工厂模式
UML图
假如有一位爱心人士，想给饥饿的流浪动物喂食。此时爱心人士身带了狗粮，但是他到处找啊找，最终只找到了猫大人，是不是有点惨兮兮。但是如果有简单工厂模式，如下图所示，这位爱心人士找到一家刚刚成立的流浪动物收容所，进去之后只要询问管理员，狗大人在哪里，我要去给它献贡。管理员根据你提出的条件，立马带你去参拜。
概念
简单工厂模式是属于创建型模式，又叫做静态工厂方法（Static Factory Method）模式，但不属于23种GOF设计模式之一。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。
优点
工厂类是整个模式的关键。包含了必要的逻辑判断，根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过使用工厂类，外界可以从直接创建具体产品对象的尴尬局面摆脱出来，仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点
但由于工厂类集中了所有实例的创建逻辑，违反了高内聚低耦合原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求。这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；
这些缺点在工厂方法模式中得到了一定的克服。
工厂方法模式
UML图
过了3年之后，善良的人越来越多，大家把各种流浪动物送到了流浪工厂，并隔三岔五的送食物过来。爱心人士由原来的一位变成了一堆，管理员每天累的要命，终于鼓起勇气提出了离职。厂长一看，这怎么行，你走了难道要我堂堂一个厂长去指路吗。于是狠心决定加大投资，先设计好工厂要怎么干才能让这些爱心人士方便自己喂养，然后依照此规定增加几个小工厂，把流浪动物分类。让善良的人自己去找工厂，自己去喂养吧。
概念
工厂方法模式（FACTORY METHOD）是一种常用的类创建型设计模式,。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。它的核心结构有四个角色，分别是抽象工厂；具体工厂；抽象产品；具体产品。
优点
- 在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。（比如上面爱心人士只要找打了对的工厂，手里的食物一定能投出去）
- 基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。
- 使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”。
缺点
- 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
- 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。
对比总结
经过上面的故事和叙述，其实已经大概了解了工厂方法模式比简单工厂多干了啥，总结如下：
- 工厂方法模式完全符合面向对象设计的核心原则：开放-封闭原则。
- 工厂方法模式投入比简单工厂模式要大，正如故事中，厂长不得不增加投入建新厂。对比我们编码也是投入大，但是带来的可维护性是非常高的，毕竟厂长和管理员都舒服了，爱心人士其实也舒服了。
- 工厂方法模式的使用对开发者来说更需要一定的抽象能力，没有这种能力之前，千万不要乱用（设计模式也是如此）。
除此之外，工厂家族还有一个，咱下次再继续对比 ，未完待续!