读书的时候有学习了解过设计模式，但是都是浅谈于书面，实际场景是没有的，所以会导致只是知道了这种情况，具体其实中奥妙是很难深刻领会的。
工作久了，很多业务场景开始支撑我们使用，对于设计模式的体会也是更深刻了一点，抽空来总结下基于工作实践后，我对于设计模式的理解。

什么是设计模式

基于官方说法：是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
使用后的理解：对代码开发经验的总结，是解决特定问题的一系列套路，能快速选择匹配自己实际业务场景。它既是经验的总结，又是一个模板和套路。真的经过实践以后对于设计模式的理解，更加觉得他是一套于己于他人于系统都是多赢的设计方案，他让代码编制真正工程化，项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，我想这可能就是它能被广泛应用的原因。但是它又不是语法规定，而仅仅是一套解决方案。他能为我们是提高代码可复用性、可维护性、可读性、稳健性以及安全性。能让我们在横向和纵向都能快速拓展。

常用的设计模式

目前我个人认为最常用的设计模式有：单例模式，工厂模式，观察者模式，装饰器模式，代理模式。（可能有偏差，只是个人理解，和套用实际场景更多的情况）

单例模式

####单例模式的定义
个人理解，单例是指单个实例，在整个应用程序当中有且仅有一个实例存在，该实例是我们通过代码指定好的（自行创建的）。

为什么要使用

解决在高并发过程中，多个实例出现逻辑错误的情况。
在特定的业务场景下避免对象重复创建，节约内存。

实现的两种方式

饿汉式

顾名思义，不管有没有使用到该对象，只要程序启动成功，该单实例对象就存在。这种方式的单例模式，写法简单，类在加载时就完成了实例化，避免了线程的问题。但缺点也很明显，实例在类记载时已创建，没有实现懒加载的效果，如果实例不用便一直存在，造成内存浪费。
思路：
1.私有化构造器（外部将不能通过new的方式去创建）
2.本类内部创建静态的对象实例（在类加载时对象实例已创建）
3.提供得到实例的静态方法

/\*\*
\* 饿汉式
\*/
public class SingletonHungry {
private static SingletonHungry instance = new SingletonHungry();
public static SingletonHungry instance(){
return instance;
}
public static void main(String[] args) {
SingletonHungry instance1 = SingletonHungry.instance();
SingletonHungry instance2 = SingletonHungry.instance();
System.out.println(instance1);
System.out.println(instance2);
}
}

上述情况，满足在单线程和多线程中使用。

懒汉式

顾名思义，只有在程序当中使用到该对象的时候，该单实例对象才会被实例化。
在类加载的时候就创建好了，如何做到在用的时候才创建呢？
在当调用获取对象实例方法的时候创建就好了，然后再获取对象实例前，先判断对象实例是否存在。

ps:这样很明显是有线程安全问题的，当多个线程进入方法，都会判断到当前实例未空，接着创建了多个实例，这不是我们想要的结果。

/\*\*
\* 懒汉式-单线程
\*/
public class SingletonLazy {
public static SingletonLazy instance = null ;
public static SingletonLazy instance() {
if(instance == null) {
instance = new SingletonLazy() ;
}
return instance ;
}
}

上述编写的代码中，乍一看，没问题，满足了单实例对象。可是细细一琢磨，咋感觉这不对，如果多线程情况下，就很难保证单实例对象了。下面提供一种多线程情况下实现单例的方式：

/\*\*
\* 懒汉式-多线程
\*/
public class SingletonLazy {
public static SingletonLazy instance = null ;
public static SingletonLazy instance() {
if(instance == null ) {
synchronized (SingletonLazy.class) {
if(instance == null) {
instance = new SingletonLazy();
}
}
}
return instance ;
}
}

public static SingletonLazy instance = null ;

实际使用场景

1.比如把配置文件存在一个文件中，这些配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂情况下的配置管理。
2.windows的回收站其实就是一个单例，你双击第二次并不会在出现一个出现窗口，对象只会创建一次
3..第三方sdk做接口发送短信验证码，如果有几十万个用户同时发送短信，只需调用对象的方法即可
4.我们一般在调用数据库的时候也采用来实现的，这样避免了内存空间不必要的占用和浪费
5.再比如Hibernate的SessionFactory，它充当数据存储源的代理，并负责创建Session对象。SessionFactory并不是轻量级的，一般情况下，一个项目只需要一个SessionFactory就够了，这就是会使用到单例模式。

总结：
单例模式适合使用的场景：
1.有频繁实例化然后销毁的情况，也就是频繁的new对象，可以考虑单例模式。
2.创建对象耗时过多或者消耗资源过多，却又经常用到的对象
3.频繁创建IO资源的对象，例如数据库连接池访问本地文件

工厂模式

工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。定义一个创建对象的工厂接口，将对象的实际创建工作推迟到具体子工厂类当中。

1.优点
1、一个调用者想创建一个对象，只要知道其名称就可以了。
2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
3、屏蔽产品的具体实现，调用者只关心产品的接口。
2.缺点
每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

3.为什么要用工厂模式
(1) 解耦 ：把对象的创建和使用的过程分开
(2)降低代码重复: 如果创建某个对象的过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。
(3) 降低维护成本 ：由于创建过程都由工厂统一管理，所以发生业务逻辑变化，不需要找到所有需要创建某个对象的地方去逐个修正，只需要在工厂里修改即可，降低维护成本。

简单工厂

简单工厂模式，又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，把产品的生产方法封装起来放进工厂类，工厂类可以根据参数的不同,返回不同产品类的实例。工厂类就是用来生产产品的类，把生产产品的方法放到工厂类里面去，工厂类里面用switch语句控制生产哪种商品，使用者只需要调用工厂类的静态方法就可以实现产品类的实例化。
严格的说，简单工厂模式并不是23种常用的设计模式之一，它只算工厂模式的一个特殊实现。
它违背了我们在设计模式七大原则中所说的“开闭原则”（虽然可以通过反射的机制类避免，后面会提到）。因为每次要新添加一个功能，都需要在switch-case语句（或者if-else语句）中去修改代码，添加分支条件。

使用场景

1.需要创建的对象较少。
2.客户端不关心对象的创建过程。

实例讲解

//1.创建抽象产品类，定义具体产品的公共接口
public abstract class Car {
abstract void run();
}
//2.创建具体产品类，定义生产的具体产品
//具体产品-奥迪车
public class Audi extends Car {
@Override
void run() {
System.out.println("奥迪车,跑起来贼稳...");
}
}
//具体产品-宝马车
public class Bmw extends Car {
@Override
void run() {
System.out.println("宝马车,跑起来贼溜...");
}
}
//3.创建工厂类，提供具体的产品对象
public class CarFactory {
public static Car getCar(String type) {
Car car = null;
if ("Bmw".equalsIgnoreCase(type)) {
car = new Bmw();
} else if ("Audi".equalsIgnoreCase(type)) {
car = new Audi();
}
return car;
}
}
//4.外界通过调用工厂类的静态方法，传入不同参数从而创建不同具体产品类的实例
public class Test {
public static void main(String[] args) {
//获取奥迪车实例,并执行方法
Car audi = CarFactory.getCar("audi");
audi.run();
//获取宝马车实例,并执行方法
Car bmw = CarFactory.getCar("bmw");
bmw.run();
}
}
//结果输出：
//奥迪车,跑起来贼稳...
//宝马车,跑起来贼溜...
//这样的实现有个问题，如果我们新增产品类的话，就需要修改工厂类中的getCar（）方法，这很明显不符合开闭原则的。
//5 使用反射机制改善简单工厂
public class CarFactoryNew {
/\*\*
\* 利用反射解决简单工厂每次增加新产品类都要修改产品工厂的弊端
\*
\*/
public static Object getClass(Class<? extends Car> clazz) {
Object obj = null;
try {
obj = Class.forName(clazz.getName()).newInstance();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
return obj;
}
}
//此时增加比亚迪汽车，并进行测试
//比亚迪汽车
public class Byd extends Car{
@Override
void run() {
System.out.println("比亚迪汽车，跑起来贼快");
}
}
//测试方法
public class TestNew {
public static void main(String[] args) {
Audi audi = (Audi) CarFactoryNew.getClass(Audi.class);
audi.run();
Bmw bmw = (Bmw) CarFactoryNew.getClass(Bmw.class);
bmw.run();
Byd byd = (Byd) CarFactoryNew.getClass(Byd.class);
byd.run();
}
}
//输出结果：
//奥迪车,跑起来贼稳...
//宝马车,跑起来贼溜...
//比亚迪汽车，跑起来贼快

应用场景：
当没有使用工厂模式的时候，每个“产品”类都是分散的，没有使用一个工厂接口把它们整合起来，可能每一类都需要很多不同的参数，使用者要清晰地知道这些参数才能把“产品”类实例化，每个产品参数不同的话，会让使用者非常凌乱，使用“工厂”则可以把参数封装在里面，让使用者不用知道具体参数就可以实例化出所需要的“产品”类。

工厂方法

简单工厂模式最大的缺点就是当有新产品要加入到系统中时，必须修改工厂类，这违背了开闭原则。在工厂方法中，我们不在提供统一的工厂类来创建所有的产品对象，而是针对不同的产品提供不同的工厂。
工厂方法模式将类的实例化推迟到了工厂类的子类中完成，即由子类来决定应该实例哪一个类。工厂方法模式是简单工厂模式的延伸，是使用频率最高的设计模式之一，是很多开源框架与API类库的核心模式。

适用场景

客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体的工厂类创建。

实例讲解

//1.创建抽象工厂类
public interface Factory {
Car getCar();
}
//2.创建具体工厂类
//创建比亚迪汽车工厂
public class BydFactory implements Factory {
@Override
public Car getCar() {
return new Byd();
}
}
//创建奥迪汽车工厂
public class AudiFactory implements Factory {
@Override
public Car getCar() {
return new Audi();
}
}
//3.测试方法
public class Test {
public static void main(String[] args) {
//奥迪汽车
AudiFactory audiFactory = new AudiFactory();
audiFactory.getCar().run();
//比亚迪汽车
BydFactory bydFactory = new BydFactory();
bydFactory.getCar().run();
}
}
//输出结果：
//奥迪车,跑起来贼稳...
//比亚迪汽车，跑起来贼快

优缺点说明：

符合开闭原则，新增加一种产品时，只需要增加相应的具体产品类和相应的工厂子类即可；

一个具体工厂只能创建一种具体的产品；

抽象工厂

工厂方法模式通过引入工厂等级结构，解决了简单工厂模式中工厂类职责太重的问题，但由于工厂方法模式中的每个工厂只能生产一类产品，可能会导致系统中存在大量的工厂类，势必增加系统的开销。此时，我们可以考虑将一些相关的产品组成一个“产品族”，由同一个工厂来统一生产

适用场景

一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是很重要的，用户无须关心对象的创建过程，将对象的创建和使用解耦
系统中有多于一个的产品族，而每次只使用其中某一产品族。可以通过配置文件等方式来使得用户可以动态改变产品族，也可以很方便地增加新的产品族

实例讲解

//1.创建抽象工厂类，定义具体工厂的公共接口
public abstract class Factory {
abstract Mobile makeMobile();
abstract Ipad makeIpad();
}

//2.创建抽象产品类，定义具体产品的公共接口
//手机产品抽象类
public abstract class Mobile {
abstract void show();
}
//平板产品抽象类
public abstract class Ipad {
abstract void show();
}
//3.创建具体产品类，定义生产的具体产品
//华为手机产品
public class HuaWeiMobile extends Mobile {
@Override
void show() {
System.out.println("华为手机，您手中的世界500强。。。");
}
}
//小米手机产品
public class XiaoMiMobile extends Mobile {
@Override
void show() {
System.out.println("小米手机，为发烧而生");
}
}
//华为平板产品
public class HuaWeiIpad extends Ipad {
@Override
void show() {
System.out.println("华为平板，很不错。。。");
}
}
//小米平板产品
public class XiaoMiIpad extends Ipad {
@Override
void show() {
System.out.println("小米平板，很棒。。。");
}
}
//4.创建具体工厂类，定义创建对应具体产品实例的方法
/\*\*
\*     华为工厂
\*/
public class HuaWeiFactory extends Factory {
@Override
Mobile makeMobile() {
return new HuaWeiMobile();
}
@Override
Ipad makeIpad() {
return new HuaWeiIpad();
}
}
/\*\*
\*     小米工厂
\*/
public class XiaoMiFactory extends Factory {
@Override
Mobile makeMobile() {
return new XiaoMiMobile();
}
@Override
Ipad makeIpad() {
return new XiaoMiIpad();
}
}
//5.测试

public class Test {
public static void main(String[] args) {
HuaWeiFactory huaWeiFactory = new HuaWeiFactory();
XiaoMiFactory xiaoMiFactory = new XiaoMiFactory();
//生产华为手机
huaWeiFactory.makeMobile().show();
//生产华为平板
huaWeiFactory.makeIpad().show();
//生产小米手机
xiaoMiFactory.makeMobile().show();
//生产小米平板
xiaoMiFactory.makeIpad().show();
}
}
//输出结果
//华为手机，您手中的世界500强。。。
//华为平板，很不错。。。
//小米手机，为发烧而生
//小米平板，很棒。。。

优缺点说明

1.抽象工厂模式将具体产品的创建延迟到具体工厂的子类中，这样将对象的创建封装起来，可以减少客户端与具体产品类之间的依赖，从而使系统耦合度低，这样更有利于后期的维护和扩展；
2.新增一种产品类时比如（苹果手机和平板），只需要增加相应的具体产品类和相应的工厂子类即可，符合开闭原则
3.抽象工厂很难支持新种类产品的变化，需要添加新的产品时（比如新增电视机产品），就必须修改抽象工厂的接口以及所有的子类工厂，这样也就违背了开闭原则
4.对于新的产品族符合开闭原则；对于新的产品种类不符合开闭原则，这一特性称为开闭原则的倾斜性。

三种工厂模式角色比对

本文作者：琉璃@涂鸦智能安全团队
漏洞悬赏计划：涂鸦智能安全响应中心（https://src.tuya.com）欢迎白帽子来探索。
招聘内推计划：涵盖安全开发、安全测试、代码审计、安全合规等所有方面的岗位，简历投递[email protected]，请注明来源。