对象相关的三类职责：
对象本身所具有的职责
创建对象的职责
使用对象的职责
java中创建对象的方式：new、反射、clone()、序列化、工厂类。
class LoginAction{
private UserDao userDao;
public LoginAction(){
//创建和使用耦合
userDao = new JDBCUserDao();
}
public void execute(){
userDao.findUserById();
}
}
两个类的关系应该仅仅是A创建B或者A使用B，而不是两种都有。
创建与使用分离：防止用来实例化一个类的数据和代码在多个类中到处都是，可以将有关创建的知识搬移到一个工厂类中。有时候我们创建一个对象不只是简单调用构造函数，还需要一些参数，配置环境。
如果产品类简单，不存在太多变数，构造简单，无需提供工厂类。如String类。
一、简单工厂模式
定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态(static)方法，因此简单工厂模式又被称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。
使用时，首先对产品类进行重构，根据实际情况设计一个产品层次结构，将所有产品类的公共代码移至抽象产品类，简单工厂方法根据传入的参数不同可以创建不同的产品对象。
问题：客户端创建具体产品时，需要修改简单工厂方法的参数，违反“开闭原则”。
改进：将参数存储在XML或properties的配置文件中，利用工具类直接读取参数。
简单工厂模式的简化：将抽象产品类和工厂类合并。
主要优点
1、对象创建和使用的分离。
2、客户端只需要知道具体产品类对应的参数，无需知道具体产品类的类名。
3、引入配置文件，不修改客户端代码的情况下更换具体产品类。
主要缺点
1、工厂类集中所有产品的创建逻辑，职责过重，一旦不正常，整个系统都受影响。
2、增加类的数量，增加复杂度和理解难度。
3、新增产品要修改工厂类逻辑，产品类较多时，可能造成逻辑过于复杂，不利于系统扩展和维护。
4、简单工厂模式使用静态工厂方法，造成工厂角色无法形成基于继承的等级结构。
适用场景：
1、工厂类负责创建的对象比较少，由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
2、客户端只知道传入工厂类的参数，对于如何创建对象并不关心。
二、工厂方法模式
问题：
1、工厂类过于庞大，包含大量if...else..代码，职责过大，不利于维护和测试。
2、新增日志记录器，需要修改工厂业务逻辑。
定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。工厂方法模式又简称为工厂模式(Factory Pattern)，又可称作虚拟构造器模式(Virtual Constructor Pattern)或多态工厂模式(Polymorphic Factory Pattern)。工厂方法模式是一种类创建型模式。
具体工厂类在实现工厂方法时除了创建具体产品对象之外，还可以负责产品对象的初始化工作以及一些资源和环境配置工作，例如连接数据库、创建文件等。
反射与配置文件
在客户端代码中不使用new创建工厂对象，将具体的工厂类的类名存储在配置文件中，利用Java反射根据类名字符串生成对象。
问题：为什么不直接在客户端通过反射生成产品对象？
工厂除了对象的创建和使用分离，还有创建前后初始化（配置环境、设置参数等）代码封装到工厂中。
重载的工厂方法
提供默认参数、配置参数、文件路径等方式初始化日志记录器。
工厂方法的隐藏
在工厂类中直接调用产品类的业务方法（writeLogger()），客户端无须调用工厂方法创建产品。
主要优点
1、工厂方法创建产品，向客户隐藏了具体哪种产品类被实例化，用户只需要关心所需要产品对应的工厂，无须关心创建细节。
2、基于工厂角色和产品角色的多态性是工厂方法模式的关键。
3、加入新产品时，无须修改抽象工厂、抽象产品、客户端和其他具体工厂和具体产品，完全符合“开闭原则”。
主要缺点
1、添加新产品时，类的个数成对增加，给系统带来额外开销。
2、引入抽象层，增加抽象性和理解难度，使用DOM和反射等技术，增加了实现难度。
适用场景
1、客户端不知道它所需要的对象类。
2、抽象工厂类通过其子类来指定创建哪个对象。（多态性和里氏替换原则）
三、抽象工厂模式
工厂方法模式引入工厂等级结构，解决了简单工厂模式中工厂类职责太重的问题，但每个工厂只生产一类产品，可能导致系统中存在大量的工厂类，势必会增加系统开销。
“将一些相关的产品组成一个“产品簇”，由一个工厂来统一生产。”(Java语言的AWT包)
产品等级结构与产品簇
（1）产品等级结构：产品的继承结构。如抽象电视机是父类，而具体品牌的电视机是其子类。
（2）产品族：由同一个工厂生产的，位于不同产品等级结构中的一组产品。如海尔电器工厂生产的海尔电视机、海尔电冰箱构成一个产品族。
不同颜色的多个正方形、圆形和椭圆形分别构成了三个不同的产品等级结构，而相同颜色的正方形、圆形和椭圆形构成了一个产品族，每一个形状对象都位于某个产品族，并属于某个产品等级结构。
抽象工厂模式是所有工厂模式中最为抽象和最具一般性的一种形式
当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中所有对象时，抽象工厂模式比工厂方法模式更为简单、效率。（减少类的个数）
提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式。为创建一组对象提供了一种解决方案。
引入XMLUtil工具类和配置文件，让系统具备良好的灵活性和可扩展性。
在实际环境中，我们可以提供可视化界面，例如菜单或者窗口来修改配置文件，用户无须直接修改配置文件。
如果需要增加新的皮肤，只需增加一族新的具体组件并对应提供一个新的具体工厂。
“开闭原则”的倾斜性
抽象工厂模式最大的缺点 :在增加新的产品族很方便，但是增加新的产品等级结构很麻烦，抽象工厂模式的这种性质称为“开闭原则”的倾斜性。
1、增加产品族：对于增加新的产品族，抽象工厂模式很好地支持了“开闭原则”，只需要增加具体产品并对应增加一个新的具体工厂，对已有代码无须做任何修改。
2、增加新的产品等级结构：对于增加新的产品等级结构，需要修改所有的工厂角色，包括抽象工厂类，在所有的工厂类中都需要增加生产新产品的方法，违背了“开闭原则”。
主要优点
1、
隔离了具体类的生成，使得客户并不需要知道什么被创建。
2、当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。
3、加新的产品族很方便，无须修改已有系统，符合“开闭原则”。
主要缺点
增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了“开闭原则”。
使用场景
1、一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节。
2、系统中有多于一个的产品族，而每次只使用其中某一产品族。
3、属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。同一个产品族中的产品可以是没有任何关系的对象，但是它们都具有一些共同的约束，如同一操作系统下的按钮和文本框，按钮与文本框之间没有直接关系，但它们都是属于某一操作系统的，此时具有一个共同的约束条件：操作系统的类型。
4、产品等级结构稳定，设计完成之后，不会向系统中增加新的产品等级结构或者删除已有的产品等级结构。