设计模式

工厂模式

简单工厂模式

https://www.cnblogs.com/cxjchen/p/3143633.html

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

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

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

优点
1.隐藏了对象创建的细节，将产品的实例化推迟到子类中实现。 2.客户端基本不用关心使用的是哪个产品，只需要知道用哪个工厂就行了，提供的类型也可以用比较便于识别的字符串。 3.方便添加新的产品子类，每次只需要修改工厂类传递的类型值就行了。 4.遵循了依赖倒转原则。

缺点
1.要求产品子类的类型差不多，使用的方法名都相同，如果类比较多，而所有的类又必须要添加一种方法，则会是非常麻烦的事情。或者是一种类另一种类有几种方法不相同，客户端无法知道是哪一个产品子类，也就无法调用这几个不相同的方法。 2.每添加一个产品子类，都必须在工厂类中添加一个判断分支，这违背了开放-封闭原则。

工厂模式

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

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

缺点 与简单工厂模式差不多。

抽象工厂模式

单例模式

一般情况下，我们建立的一些类是属于工具性质的，基本不用存储太多的跟自身有关的数据，在这种情况下，每次都去new一个对象，即增加了开销，也使得代码更加臃肿。其实，我们只需要一个实例对象就可以。如果采用全局或者静态变量的方式，会影响封装性，难以保证别的代码不会对全局变量造成影响。

单例模式非常好实现，直接就可以在静态区初始化instance，然后通过getInstance返回，这种就被称为饿汉式单例类。也有些写法是在getInstance中new instance然后返回，这种就被称为懒汉式单例类。