1，简单工厂模式：
原文：http://www.cnblogs.com/guoshiandroid/archive/2010/06/23/1763062.html
简单工厂模式解释：
简单工厂模式（Simple Factory Pattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethod Pattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
简单工厂模式的UML图：
简单工厂模式中包含的角色及其相应的职责如下：
工厂角色（Creator）：这是简单工厂模式的核心，由它负责创建所有的类的内部逻辑。当然工厂类必须能够被外界调用，创建所需要的产品对象。
抽象（Product）产品角色：简单工厂模式所创建的所有对象的父类，注意，这里的父类可以是接口也可以是抽象类，它负责描述所有实例所共有的公共接口。
具体产品（Concrete Product）角色：简单工厂所创建的具体实例对象，这些具体的产品往往都拥有共同的父类。
简单工厂模式深入分析：
简单工厂模式解决的问题是如何去实例化一个合适的对象。
简单工厂模式的核心思想就是：有一个专门的类来负责创建实例的过程。
具体来说，把产品看着是一系列的类的集合，这些类是由某个抽象类或者接口派生出来的一个对象树。而工厂类用来产生一个合适的对象来满足客户的要求。
如果简单工厂模式所涉及到的具体产品之间没有共同的逻辑，那么我们就可以使用接口来扮演抽象产品的角色；如果具体产品之间有功能的逻辑或，我们就必须把这些共同的东西提取出来，放在一个抽象类中，然后让具体产品继承抽象类。为实现更好复用的目的，共同的东西总是应该抽象出来的。
在实际的的使用中，抽闲产品和具体产品之间往往是多层次的产品结构，如下图所示：
简单工厂模式的优缺点分析：
优点：工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。
缺点：由于工厂类集中了所有实例的创建逻辑，这就直接导致一旦这个工厂出了问题，所有的客户端都会受到牵连；而且由于简单工厂模式的产品室基于一个共同的抽象类或者接口，这样一来，但产品的种类增加的时候，即有不同的产品接口或者抽象类的时候，工厂类就需要判断何时创建何种种类的产品，这就和创建何种种类产品的产品相互混淆在了一起，违背了单一职责，导致系统丧失灵活性和可维护性。而且更重要的是，简单工厂模式违背了“开放封闭原则”，就是违背了“系统对扩展开放，对修改关闭”的原则，因为当我新增加一个产品的时候必须修改工厂类，相应的工厂类就需要重新编译一遍。
总结一下：简单工厂模式分离产品的创建者和消费者，有利于软件系统结构的优化；但是由于一切逻辑都集中在一个工厂类中，导致了没有很高的内聚性，同时也违背了“开放封闭原则”。另外，简单工厂模式的方法一般都是静态的，而静态工厂方法是无法让子类继承的，因此，简单工厂模式无法形成基于基类的继承树结构。
简单工厂模式的实际应用简介：
作为一个最基本和最简单的设计模式，简单工厂模式却有很非常广泛的应用，我们这里以Java中的JDBC操作数据库为例来说明。
JDBC是SUN公司提供的一套数据库编程接口API，它利用Java语言提供简单、一致的方式来访问各种关系型数据库。Java程序通过JDBC可以执行SQL语句，对获取的数据进行处理，并将变化了的数据存回数据库，因此，JDBC是Java应用程序与各种关系数据进行对话的一种机制。用JDBC进行数据库访问时，要使用数据库厂商提供的驱动程序接口与数据库管理系统进行数据交互。
客户端要使用使用数据时，只需要和工厂进行交互即可，这就导致操作步骤得到极大的简化，操作步骤按照顺序依次为：注册并加载数据库驱动，一般使用Class.forName();创建与数据库的链接Connection对象；创建SQL语句对象preparedStatement(sql)；提交SQL语句，根据实际情况使用executeQuery()或者executeUpdate()；显示相应的结果；关闭数据库。
温馨提示：
严格意义上讲，简单工厂模式并不算是一种设计模式，简单工厂模式更像是一种编程习惯，而这被广泛的应用。但是因为简单工厂模式在“高内聚”方面的欠缺，同时更致命的是违背了严格意义上的“开放封闭原则”，或者说只对“开放封闭原则”提供某种程度上的支持，这就使得每次新增加一个产品的时候是非常麻烦的，因为每当增加一种新的产品的时候，工厂角色必须知道这个产品，同时必须知道如何创建这个产品，还要以一种对客户端有好的方式提供给客户端使用。简而言之，就是每增加一个新的产品就必须修改工厂角色的源代码。所以简单工厂模式是不利于构建容易发生变化的系统的。而“需求总是在变化”，“世界上没有一个软件是不变的”。所以使用简单工厂模式的时候必须慎重考虑。
2，工厂方法模式
原文：http://www.cnblogs.com/guoshiandroid/archive/2010/06/25/1764813.html
工厂方法法模式模式解释：
工厂方法模式（Factory Method Pattern）同样属于类的创建型模式又被称为多态工厂模式(Polymorphic) 。工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。
英文定义为：Define an interface for creating an object, but let subclassesdecide which class to instantiate. Factory Method lets a class deferinstantiation to subclasses.
工厂方法模式的UML图：
工厂方法模式中包含的角色及其相应的职责如下：
抽象工厂（Creator）角色：工厂方法模式的核心，任何工厂类都必须实现这个接口。
具体工厂（ Concrete Creator）角色: 具体工厂类是抽象工厂的一个实现，负责实例化产品对象。
抽象（Product）产品角色：简单工厂模式所创建的所有对象的父类，注意，这里的父类可以是接口也可以是抽象类，它负责描述所有实例所共有的公共接口。
具体产品（Concrete Product）角色：简单工厂所创建的具体实例对象，这些具体的产品往往都拥有共同的父类。
工厂方法法模式深入分析：
简单工厂模式使用一个类负责所有产品的创建，虽然使得客服端和服务端相互分离，使得客服端不用关心产品的具体创建过程，客户端唯一所要做的就是调用简单工厂的静态方法获得想要的产品即可。但是，简单工厂模式违背了严格意义上的“开放封闭原则”，这就使得一旦有一个新的产品增加就必须修改工厂类的源代码，从而将新的产品的创建逻辑加入简单工厂中供客户端调用。工厂方法法模式正是在简单工厂模式的基础上进一步抽象而来的。由于工厂方法法模式的核心是抽象工厂角色，使用了面向对象的多态性，这就使得工厂方法法模式即保持了简单工厂模式的优点，又克服了简单工厂模式违背“开放封闭原则”的缺点。
工厂方法法模式中核心工厂类不再提供所有的产品的创建工作，而是将具体的产品创建工作交给了子类去做。这时候的核心工厂类做什么呢？做标准！核心工厂类只需要负责制定具体工厂需要实现的接口即可，至于具体的工作就留给了子类去创建了。
在实际的的使用中，抽闲产品和具体产品之间往往是多层次的产品结构，如下图所示：
工厂方法模式的优缺点分析：
优点：工厂方法类的核心是一个抽象工厂类，所有具体的工厂类都必须实现这个接口。当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要修改客户端，这就很好的符合了“开放－封闭”原则。
缺点：使用工厂方法模式的时候，客户端需要决定实例化哪一个具体的工厂。也就是说工厂方法法模式把简单工厂模式的内部判断逻辑转移到了客户端代码。而且使用该模式需要增加额外的代码，这就导致工作量的增加。
3，抽象工厂模式
原文：http://www.cnblogs.com/guoshiandroid/archive/2010/06/27/1765979.html
抽象工厂模式解释：
抽象工厂模式（Abstact Factory Pattern）是所有形态的工厂模式中最为抽象和最其一般性的。抽象工厂模式可以向客户端提供一个接口，使得客户端在不必指定产品的具体类型的情况下，能够创建多个产品族的产品对象。
抽象工厂中方法对应产品结构，具体工厂对应产品族
英文定义为：Provide an interface forcreating families of related or dependent objects without specifying theirconcrete classes.
抽象工厂模式的UML图：
抽象工厂模式模式中包含的角色及其相应的职责如下：
抽象工厂（Creator）角色：抽象工厂模式的核心，包含对多个产品结构的声明，任何工厂类都必须实现这个接口。
具体工厂（Concrete Creator）角色: 具体工厂类是抽象工厂的一个实现，负责实例化某个产品族中的产品对象。
抽象（Product）产品角色：抽象模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。
具体产品（Concrete Product）角色：抽象模式所创建的具体实例对象。
抽象工厂模式深入分析：
抽象工厂模式是在当产品有多个 抽象角色的时候使用的一种创建型设计模式。
按照里氏代换原则，凡是父类适用的地方，子类也必然适用。而在实际系统中，我们需要的是和父类类型相同的子类的实例对象，而不是父类本身，也就是这些抽象产品的具体子类的实例。具体工厂类就是来负责创建抽象产品的具体子类的实例的。
当每个抽象产品都有多于一个的具体子类的时候，工厂角色是如何确定实例化哪一个子类呢？例如说有两个抽象产品角色，而每个抽象产品角色都有两个具体产品。抽象工厂模式提供两个具体工厂角色，分别对应于这两个具体产品角色，每一个具体工厂角色只负责某一个产品角色的实例化。每一个具体工厂类只负责创建抽象产品的某一个具体子类的实例。
每一个模式都是针对一定问题的解决方案，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式针对的是多个产品等级结构。
何谓产品族？产品族是指位于不同产品等级结构中，功能相关联的产品组成的家族。一般是位于不同的等级结构中的相同位置上。显然，每一个产品族中含有产品的数目，与产品等级结构的数目是相等的，形成一个二维的坐标系，水平坐标是产品等级结构，纵坐标是产品族。
对于每一个产品族，都有一个具体工厂。而每一个具体工厂创建属于同一个产品族，但是分属于不同等级结构的产品。
通过引进抽象工厂模式，可以处理具有相同（或者相似）等级结构的多个产品族中的产品对象的创建问题。
由于每个具体工厂角色都需要负责不同等级结构的产品对象的创建，因此每个工厂角色都需要提供相应数目的工厂方法，分别用于创建相应数目的等级结构的产品。
如下图所示：
抽象工厂模式使用场景分析及代码实现：
MM过生日的时候还是要到麦当劳，但是这次要求是到华联那边的麦当劳去，就是地方不同了，要换换口味和心情。这就是抽象工厂模式的一个很好的体现。首先对不同的麦当劳分店而言，每一种产品，例如说汉堡，都是汉堡，但是每个地方的汉堡在遵循统一标准的前提下又会尽力突出自己的特色，这样这样才能更好的吸引和留住顾客，因为不同的地方，随着环境等的不同，人们的喜好和口味等都会有所不同，但是无论怎么不同，始终还是汉堡，具有汉堡的基本功能。同时，每一个分店都有一系列的产品，例如汉堡、鸡翅等等，这就构成了产品的等级结构。
总之：麦当劳总部相当于抽象工厂，每个分店相当于具体工厂，而每种产品又有所不同。这样在既保持了统一性的前提下，又使得各分店的特色有所不同，适合于吸引和留住不同环境下的客户。
UML模型图如下所示：
抽象工厂模式的优缺点分析：
优点：客户端不再负责对象的具体创建，而是把这个责任交给了具体的工厂类，客户端之负责对对象的调用。当具有产品家族性质的产品被涉及到一个工厂类中后，对客户端而言是非常友好的，更重要的是如果想要更换为另外一产品家族，所要做的只是需要增加相应的产品家族成员和增加一个具体的产品工厂而已。
缺点：当有新的产品加入的时候，也就是当产品的结构发生改变时，修要修改抽象工厂类的设计，这就导致了必须修改所有的具体工厂类，导致很客观的工作量的增加。
抽象工厂模式的实际应用简介：
抽象工厂模式是针对多个产品系列的创建的问题，这在持久化层的设计很实现中有很大的指导意义。由于Java的跨平台性，一般而言，持久化层都要考虑到都肿数据库的问题，例如MySQL、Oracle等，每一个数据库就相当于一个产品系列，持久化层必须设计好好不同产品系列的共同接口，这样才便于使用者操作数据库，同时也有利于数据库的移植。大名鼎鼎的Hibernate就很好的借鉴了抽象工厂模式的设计方法。
温馨提示：
抽象工厂模式考虑的是不同产品系列的创建的问题，并非能到处使用。另外在新增加产品的时候，需要改变抽象工厂的设计，这会导致很大的工作量，所以在规划之初必须考虑好产品的结构，力求降低参加产品的可能性，是抽象工厂比较稳定。