设计模式（一）工厂模式（转）

原文地址（http://www.cnblogs.com/cxjchen/p/3143633.html）

简单工厂模式

简单工厂模式是工厂模式中最简单的一种，他能够用比较简单的方式隐藏建立对象的细节，通常只须要告诉工厂类所须要的类型，工厂类就会返回须要的产品类，但客户端看到的只是产品的抽象对象，无需关心究竟是返回了哪一个子类。客户端惟一须要知道的具体子类就是工厂子类。除了这点，基本是达到了依赖倒转原则的要求。

 

假如，咱们不用工厂类，只用AbstractProduct和它的子类，那客户端每次使用不一样的子类的时候都须要知道究竟是用哪个子类，当类比较少的时候还没什么问题，可是当类比较多的时候，管理起来就很是的麻烦了，就必需要作大量的替换，一个不当心就会发生错误。

而使用了工厂类以后，就不会有这样的问题，无论里面多少个类，我只须要知道类型号便可。不过，这里还有一个疑问，那就是若是我每次用工厂类建立的类型都不相同，这样修改起来的时候仍是会出现问题，仍是须要大量的替换。因此简单工厂模式通常应该于程序中大部分地方都只使用其中一种产品，工厂类也不用频繁建立产品类的状况。这样修改的时候只须要修改有限的几个地方便可。

客户只须要知道SimpleFactory就能够了，使用的时候也是使用的AbstractFactory，这样客户端只在第一次建立工厂的时候是知道具体的细节的，其余时候它都只知道AbstractFactory，这样就完美的达到了依赖倒转的原则。

经常使用的场景

例如部署多种数据库的状况，可能在不一样的地方要使用不一样的数据库，此时只须要在配置文件中设定数据库的类型，每次再根据类型生成实例，这样，无论下面的数据库类型怎么变化，在客户端看来都是只有一个AbstractProduct，使用的时候根本无需修改代码。提供的类型也能够用比较便于识别的字符串，这样不用记很长的类名，还能够保存为配置文件。

这样，每次只须要修改配置文件和添加新的产品子类便可。

因此简单工厂模式通常应用于多种同类型类的状况，将这些类隐藏起来，再提供统一的接口，便于维护和修改。

优势

1.隐藏了对象建立的细节，将产品的实例化推迟到子类中实现。

2.客户端基本不用关心使用的是哪一个产品，只须要知道用哪一个工厂就好了，提供的类型也能够用比较便于识别的字符串。

3.方便添加新的产品子类，每次只须要修改工厂类传递的类型值就好了。

4.遵循了依赖倒转原则。

缺点

1.要求产品子类的类型差很少，使用的方法名都相同，若是类比较多，而全部的类又必需要添加一种方法，则会是很是麻烦的事情。或者是一种类另外一种类有几种方法不相同，客户端没法知道是哪个产品子类，也就没法调用这几个不相同的方法。

2.每添加一个产品子类，都必须在工厂类中添加一个判断分支，这违背了开放-封闭原则。

---

工厂模式

工厂模式基本与简单工厂模式差很少，上面也说了，每次添加一个产品子类都必须在工厂类中添加一个判断分支，这样违背了开放-封闭原则，所以，工厂模式就是为了解决这个问题而产生的。

既然每次都要判断，那我就把这些判断都生成一个工厂子类，这样，每次添加产品子类的时候，只需再添加一个工厂子类就能够了。这样就完美的遵循了开放-封闭原则。但这其实也有问题，若是产品数量足够多，要维护的量就会增长，好在通常工厂子类只用来生成产品类，只要产品子类的名称不发生变化，那么基本工厂子类就不须要修改，每次只须要修改产品子类就能够了。

一样工厂模式通常应该于程序中大部分地方都只使用其中一种产品，工厂类也不用频繁建立产品类的状况。这样修改的时候只须要修改有限的几个地方便可。

 

经常使用的场景

基本与简单工厂模式一致，只不过是改进了简单工厂模式中的开放-封闭原则的缺陷，使得模式更具备弹性。将实例化的过程推迟到子类中，由子类来决定实例化哪一个。

优势

基本与简单工厂模式一致，多的一点优势就是遵循了开放-封闭原则，使得模式的灵活性更强。

缺点

与简单工厂模式差很少。

---

抽象工厂模式

抽象工厂模式就变得比工厂模式更为复杂，就像上面提到的缺点同样，工厂模式和简单工厂模式要求产品子类必需要是同一类型的，拥有共同的方法，这就限制了产品子类的扩展。因而为了更加方便的扩展，抽象工厂模式就将同一类的产品子类归为一类，让他们继承同一个抽象子类，咱们能够把他们一块儿视做一组，而后好几组产品构成一族。

此时，客户端要使用时必须知道是哪个工厂而且是哪一组的产品抽象类。每个工厂子类负责产生一族产品，而子类的一种方法产生一种类型的产品。在客户端看来只有AbstractProductA和AbstractProductB两种产品，使用的时候也是直接使用这两种产品。而经过工厂来识别是属于哪一族产品。

产品ProductA_1和ProductB_1构成一族产品，对应于有Factory1来建立，也就是说Factory1老是建立的ProductA_1和ProductB_1的产品，在客户端看来只须要知道是哪一类工厂和产品组就能够了。通常来讲， ProductA_1和ProductB_1都是适应同一种环境的，因此他们会被归为一族。

经常使用的场景

例如Linux和windows两种操做系统下，有2个挂件A和B，他们在Linux和Windows下面的实现方式不一样，Factory1负责产生能在Linux下运行的挂件A和B，Factory2负责产生能在Windows下运行的挂件A和B，这样若是系统环境发生变化了，咱们只须要修改工厂就好了。

优势

1.封装了产品的建立，使得不须要知道具体是哪一种产品，只须要知道是哪一个工厂就好了。

2.能够支持不一样类型的产品，使得模式灵活性更强。

3.能够很是方便的使用一族中间的不一样类型的产品。

缺点

1.结构太过臃肿，若是产品类型比较多，或者产品族类比较多，就会很是难于管理。

2.每次若是添加一组产品，那么全部的工厂类都必须添加一个方法，这样违背了开放-封闭原则。因此通常适用于产品组合产品族变化不大的状况。