【工业化面试】之设计模式

前言

设计模式是后端开发(主要指java开发)面试中必不可少的考察内容之一，但是设计模式总共有23种之多，全部掌握需要很长时间，本文从面试的角度出发，总结了以下几个常考的设计模式(面试官通常会问我们了解哪些设计模式，这时候就是我们自由发挥的时间，讲好了会加分)。

正文

1、 单例模式

确保每个类只有一个实例，并提供公共接口供全局访问。主要结构是：私有的构造函数、私有的静态变量、公有的静态函数实现。

1. 懒汉式：需要使用时才初始化对象实例。
2. 饿汉式：一开始就初始化好对象。

单例模式代码(双检锁)：

public class Singleton {
    private static volatile Singleton singleton = null;
        private Singleton() {
        }
        public static Singleton getInstance(){
            //第一次校验singleton是否为空
            if(singleton==null){
                synchronized (Singleton.class){
                    //第二次校验singleton是否为空
                    if(singleton==null){
                        singleton = new Singleton();
                    }
                }
            }
            return singleton;
}
}

2、 工厂模式

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。它适用于工厂类负责创建对象较少的情况，且客户端只需要传入工厂类的参数，对于如何创建对象不关心。
工厂方法模式（Factory Method Pattern）是指定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，工厂方法模式让类的实例化推迟到子类中进行。在工厂方法模式中，用户只需要关心所需产品对应工厂，无须关心创建的细节，而且加入新产品时符合开闭原则。
抽象工厂模式是工厂方法的仅一步深化，在这个模式中的工厂类不单单可以创建一种产品，而是可以创建一 组产品。

3、 适配器模式

适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
当我们想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。

4、 装饰器模式

装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。在不想增加很多子类的情况下扩展类。
举个例子：在我们的项目中遇到这样一个问题：我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。我们以往在spring和hibernate框架中总是配置一个数据源，因而sessionFactory的dataSource属性总是指向这个数据源并且恒定不变，所有DAO在使用sessionFactory的时候都是通过这个数据源访问数据库。但是现在，由于项目的需要，我们的DAO在访问sessionFactory的时候都不得不在多个数据源中不断切换，问题就出现了：如何让sessionFactory在执行数据持久化的时候，根据客户的需求能够动态切换不同的数据源？我们能不能在spring的框架下通过少量修改得到解决？是否有什么设计模式可以利用呢？使用装饰器模式，向现有的对象添加一些新的功能。

5、 代理模式(重点掌握)

在一些业务逻辑中，需要在业务处理前和业务处理后加上特定的逻辑处理，但是不能修改原有逻辑，此时可采用代理模式，根据原有对象，生成该对象的代理类，类似于装饰器模式。
代理模式的主要作用是扩展目标对象的功能，比如说在目标对象的某个方法执行前后你可以增加一些自定义的操作。

5.1 静态代理

静态代理中，我们对目标对象的每个方法的增强都是手动完成的，非常不灵活，比如接口一旦新增加方法，目标对象和代理对象都要进行修改，且麻烦，需要对每个目标类都单独写一个代理类。从 JVM 层面 来说， 静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。

5.2 动态代理

在动态代理中，我们不需要针对每个目标类都单独创建一个代理类，并且也 不需要我们必须实现接口，我们可以直接代理实现类( CGLIB 动态代理机制)。
动态代理分为jdk动态代理和CGLIB动态代理。
jdk动态代理是通过InvocationHandler来实现的，要实现动态代理的话，需要实现 InvocationHandler 来自定义处理逻辑。
当我们的动态代理对象调用一个方法时候，这个方法的调用就会被转发到实现 InvocationHandler 接口类的 invoke 方法来调用。invoke() 方法有下面三个参数：proxy,动态生成的代理类，method，与代理对象调用的方法向对应的方法，args，当前method需要的参数。当我们通过 Proxy 类的 newProxyInstance() 创建的代理对象在调用方法的时候，实际会调用到实现 InvocationHandler 接口的类的 invoke() 方法。 你可以在 invoke() 方法中自定义处理 逻辑，比如在方法执行前后做什么事情。
CGLIB动态代理：JDK 动态代理有一个最致命的问题是其只能代理实现了接口的类。为了解决这个问题，我们可以用 CGLIB 动态代理机制来避免。
CGLIB(Code Generation Library)是一个基于ASM的字节码生成库，它允许我们在运行时对字节码进行修 改和动态生成。需要自定义 MethodInterceptor 并重写 intercept 方法， intercept 用于拦截增强被代理类的方法。Intercept方法有四个参数：obj：被代理的对象(需要增强的对象)，method:需要被增强的方法，args:方法入参，methodProxy，用于调用的原始方法。
我们可以通过 Enhancer 类来动态获取被代理类，当代理类调用方法的时候，实际调用的是 MethodInterceptor 中的 intercept 方法。

5.3 JDK代理和CGLIB代理的区别：

JDK 动态代理只能只能代理实现了接口的类，而 CGLIB 可以代理未实现任何接口的类。 另外， CGLIB 动态代理是通过生成一个被代理类的子类来拦截被代理类的方法调用，因此不能代理声明 为 final 类型的类和方法。 2. 就二者的效率来说，大部分情况都是 JDK 动态代理更优秀，随着 JDK 版本的升级，这个优势更加 明显。

5.4 静态代理和动态代理的区别

1. 灵活性 ：动态代理更加灵活，不需要必须实现接口，可以直接代理实现类，并且可以不需要针对 每个目标类都创建一个代理类。另外，静态代理中，接口一旦新增加方法，目标对象和代理对象都 要进行修改，这是非常麻烦的！
2. JVM 层面 ：静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文 件。而动态代理是在运行时动态生成类字节码，并加载到 JVM 中的。

5.5 JDK动态代理实现步骤

定义一个接口及其实现类； 自定义 InvocationHandler 并重写 invoke 方法，在 invoke 方法中我们会调用原生方法（被 代理类的方法）并自定义一些处理逻辑； 通过 Proxy.newProxyInstance(ClassLoader loader,Class[] interfaces,InvocationHandler h) 方法创建代理对象；
5.6 CGLIB动态代理实现

1. 定义一个类；
2. 自定义 MethodInterceptor 并重写 intercept 方法， intercept 用于拦截增强被代理类的方 法，和 JDK 动态代理中的 invoke 方法类似；
3. 通过 Enhancer 类的 create() 创建代理类；

5、 观察者模式

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。