前言:这段时间在学习设计模式，本人也是小菜一枚（所以写的如果有错误的地方请大大们给予指出）。这个东西也是我一直想学习的，从点点滴滴做起，记录下自己每天的领悟！
一、工厂模式的动机
- 在软件系统中，经常面临着“某个对象”的创建工作；由于需求的变化，这个对象经常面临着剧烈的变化，但是它却拥有比较稳定的接口。
- 如何应对这种变化？如何提供一种“封装机制”来隔离出“这个易变对象”的变化，从而保持系统中“其他依赖该对象的对象”不随着需求改变而改变？
二、不同的工厂模式
- 简单工厂
- 工厂方法模式
- 抽象工厂
注：简单工厂：一个具体工厂通过条件语句创建多个产品，产品的创建逻辑集中与一个工厂类。客户端通过传不同的参数给工厂，实现创建不同产品的目的增加新产品时，需要修改工厂类、增加产品类，不符合OCP原则。
工厂方法：一个工厂创建一个产品，所有的具体工厂继承自一个抽象工厂。客户端先创建不同产品的工厂，再由工厂创建具体产品，产品的创建逻辑分散在每个具体工厂类中。客户端只依赖于抽象工厂与抽象产品，不依赖任何具体的工厂与具体产品增加新产品时，需要增加工厂类和产品类，符合OCP原则。
抽象工厂：一个具体工厂创建一个产品族，一个产品族是不同系列产品的组合，产品的创建的逻辑分在在每个具体工厂类中。所有的具体工厂继承自同一个抽象工厂。客户端创建不同产品族的工厂，产品族的工厂创建具体的产品对客户端是不可见的。增加新的产品族时，需要增加具体工厂类,符合OCP原则。增加新产品时，需要修改具体工厂类和增加产品类，不符合OCP原则。如果没有应对“多系列对象创建”的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完全可以。
三、简单工厂模式
- 解释：简单工厂模式是创建型模式，用于对象的创建，它不属于23种gof设计模式。它是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。
- 简单工厂模式的结构：
模式的结构中包括的角色：抽象产品（Product）
具体产品（ConcreteProduct）
构造者（Creator）
四、代码演示
这里我用的是一个这样的例子：用一个工厂来生产出不同类型的窗体（记住为同类产品）
1、在工厂模式中我们首先考虑的应该是产品，因为产品为窗体，所以我们抽象出的产品父类（即抽象产品Product）是所有窗体产品都有的特性 命名为Window.java对应的代码：
package com.java; /**
* 抽象的窗体类
*
* @author zhang
*
*/
public abstract class Window {
// 抽象的方法
public abstract void funct();
}
2、父级的产品写完以后就是考虑不同型号的同类（具体产品ConcreteProduct）产品了分别为WindowBig.java和WindowSmall.java
WindowBig.java对应的代码：
package com.java; /**
* 具体产品的类（大窗体）
* @author zhang
*
*/
public class WindowBig extends Window { @Override
public void funct() {
System.out.println("大窗体创建成功");
} }
WindowSmall.java对应的代码：
package com.java; /**
* 具体产品类（小窗体）
* @author zhang
*
*/
public class WindowSmall extends Window { @Override
public void funct() {
System.out.println("小窗体创建成功");
} }
3、当产品写完后就应该是对就的生产产品的工厂类（构造者Creator）了Factory.java
package com.java; /**
* 生产产品的工厂类
*
* @author zhang
*
*/
public class Factory {
// 创建窗体的方法
public Window CreateWidow(String type) {
if ("big".equals(type)) {
return new WindowBig();
} else if ("small".equals(type)) {
return new WindowSmall();
} else {
return new WindowBig();
}
}
}注：简单工厂最重要的就是Create方法，根据传入的字符来生产不同的对象（利用java的多态来实现）。
五、简单工厂模式优缺点
优点：简单工厂模式主要用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致软件的脆弱。通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点：由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
适合应用的场景：
- 工厂类负责创建的对象比较少
- 客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心
- 由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用