工厂家族——设计模式（二）

设计模式学过之后，别的模式映像深刻与否很难说，但是三个工厂模式确实记忆比较深刻的。下面就三个工厂模式：简单工厂模式（Static Factory Method）、工厂方法模式（Factory Method）、抽象工厂模式（Abstract Factory）谈一谈个人的见解，希望大家多提意见，起到抛砖引玉的效果。

简单工厂模式（Static Factory Method）

1.UML图

通过简单工厂模式的UML可以看出，他是由一个工厂类，通过抽象类，来实例化具体的类，具体类继承于抽象类。它是一种最简单的模式，仅仅把本来由客户端来完成的选择语句提炼出来，避免了客户端的臃肿。但同时我们可以注意到如果需求扩展了，那么我可以从抽象类再继承出一个具体类，这是不违背开放——封闭原则的，但是当我再工厂类调用的时候，必须修改代码，来增加新类可以被选择的能力的时候就违背了开放封闭原则——我们必须修改原来的代码。

2.优缺点

1）优点

工厂类成为整个模式的关键，由工厂类根据客户端的信息来决定实例化哪个具体类。避免了客户端进行判断而导致客户端臃肿不堪的尴尬局面，客户端仅仅需要传参调用即可，不必了解如何创建类的实例。

2）缺点

由于工厂类是整个模式的关键（所谓成也萧何，败萧何），集中了所有的判断，所以一旦这个工厂出问题将影响整个模式的运行；再者工厂创建的类必须事先可以确定，否则增加新类必须修改工厂。

3.总结

我认为简单工厂的使用可以在以下情况：

1）工厂类负责创建的场景比较少；

2）客户只知道传入的参数，对于如何创建不了解的情况；

而且，我们应该注意到简单工厂的英文名字叫 Static Factory Method， Static 所以它是一个静态的模式，对于具有固定的场景的情况比较合适。这也告诉我们歪果仁创造的东东，还是原汁原味的更有利于理解。

工厂方法模式（Factory Method）

1.UML图

从UML图我们知道，工厂方法是由抽象工厂（可以是抽象类或接口），产生具体工厂，并通过抽象产品产生的具体产品来实现对业务逻辑的封装。那它和简单工厂是什么关系呢？举个例子，假设最初我用简单工厂实现了一个生产帽子和上衣的生产逻辑，但是工厂扩大业务开始生产裤子、袜子、内衣、鞋子......如果还用简单工厂那么在工厂类的判断中将产生非常长的代码，也就是这个工厂类会变得非常大，非常复杂，并且它与每一个产品类都有联系，那么耦合性就会增大，并且违背单一职责原则（它既可以生产帽子，又可以生产上衣）。所以这个时候就需要用到工厂方法模式了。抽象工厂产生具体的帽子和上衣工厂，通过实例化不同的工厂调用具体的类来产生产品。

2.优缺点

1）优点

克服了简单工厂违背开放——封闭原则的缺陷，符合六大原则。使得工厂方法模式在不修改具体工厂方法角色的情况下，可以引入新产品。

2）缺点

小弟才疏学浅，经验不足对于它的缺点认识还不够，望大家指出。必将洗耳恭听！

3.总结

工厂方法模式作为23个设计模式之一，符合设计模式的原则，并且灵活性和可扩展性非常好，在我们的设计中会有广泛的应用。

抽象工厂模式（Abstract Factory）

1.UML图

通过UML图我们知道，抽象工厂可以任意实例化集体工厂，抽象产品既有不同的实际产品，当实例化具体产品时只需要具体工厂调用具体产品即可。当具体工厂变化时只需要修改集体工厂实例化的语句即可，不必对其他处做改动。

2.优缺点

1）优点

(1)便于交换产品系列；

(2)具体产品从客户端代码中分离出来

(3)将一个系列的产品族统一到一起创建

2）缺点

在产品族中扩展新的产品是困难的

3.总结

抽象工厂的厉害之处在于我仅仅实例化一次即可完成，一系列产品的创建。还用我说的生产衣服的工厂的例子，如果工厂对产品细分发现帽子有：礼帽、遮阳帽、普通帽子。上衣有：T恤、衬衣、西装。裤子有：牛仔、休闲裤、短裤等等，那么这时用工厂方法就很费事了，为什么呢？每个产品一个工厂，这需要多少工厂呢？所系这时利用抽象共厂的特性只需要一类有一个然后统一创建即可。

回顾

对比三个工厂模式由于各自的特点可以应用于不同的场合，并且三者由易到难循序渐进。最关键的是：设计模式的存在是由于实际的需要产生的，所以我们学习的时候不能静态的看他们，我们要在动态需求不同的时候来对比选择。