Java设计模式的常见应用场景

灰太狼 2022-06-11 02:53 326阅读 0赞

## 一、Java I/O中的设计模式 ##

### 1、适配器模式 ###

适配器模式就是把一个类的接口变换成客户端所能接受的另一种接口，从而使两个接口不匹配而无法在一起工作的两个类能够在一起工作。通常被用在一个项目需要引用一些开源框架来一起工作时，这些框架的内部都有一些关于环境信息的接口，需要从外部引入，但是外部的接口不一定能匹配，在这种情况下，就需要适配器模式来转换接口。  
![这里写图片描述][20170809172258274]  
Java的I/O类库中有许多这样的需求，如将字符串转成字节数据保存到文件中，将字节数据变成数据流等。具体来说，InputStreamReader和OutputStreamWriter就是适配器的体现。InputStreamReader实现了Reader接口，并且持有InputStream的引用，其作用是将InputStream适配到Reader。源角色就是InputStream代表的实例对象，目标角色就是Reader类。OutputStreamWriter也是类似的方式。

### 2、装饰器模式 ###

装饰器的作用是使得被装饰者功能更强大，而且装饰前后的使用方式不变。Java I/O类库中有许多不同的功能组合情况，这些不同的功能组合都是使用装饰器模式实现的。以FileInputStream为例，其类结构如下：  
![这里写图片描述][20170809171514383]  
由于java I/O库需要很多性能的各种组合，如果这些性能都是用继承来实现，那么每一种组合都需要一个类，这样就会造成大量行重复的类出现。如果采用装饰模式，那么类的数目就会大大减少，性能的重复也可以减至最少。因此装饰模式是java I/O库基本模式。装饰模式的引进，造成灵活性和复杂性的提高。因此在使用 java I/O 库时，必须理解java I/O库是由一些基本的原始流处理器和围绕它们的装饰流处理器所组成的。  
InputStream类是以抽象组件的形式存在，而FileInputStream就是具体组件，它实现了抽象接口的所有方法，并且持有InputStream对象的引用。FileInputStream就是一个装饰类，而BufferInputStream是这个装饰类的具体实现者，它给InputStream加入了新的功能，使得InputStream读取的数据保存在内存中，从而提高读取性能。

### 3、适配模式和装饰模式的区别 ###

适配模式是为了处理两个借口不一致，改变现有接口使其匹配。  
装饰模式是在不改变现有接口的前提下，加入新的功能。

## 二、Javac中的访问者模式 ##

javac 是java语言编程编译器。全称javacompilation。javac工具读由java语言编写的类和接口的定义，并将它们编译成字节代码的class文件。javac 可以隐式编译一些没有在命令行中提及的源文件。用 -verbose 选项可跟踪自动编译。当编译源文件时，编译器常常需要它还没有识别出的类型的有关信息。对于源文件中使用、扩展或实现的每个类或接口，编译器都需要其类型信息。这包括在源文件中没有明确提及、但通过继承提供信息的类和接口。  
Javac的编译过程涉及许多语法分析，所有就有语法分析器、语义分析器和代码生成器，期间需要多次遍历语法树。然而每次遍历语法树都会进行不同的处理动作，这是如何实现的呢？就是通过采用访问者模式设计的，每次遍历都是一次访问者的执行过程。  
访问者模式可以使数据结构和对数据结构的操作解耦，使得增加对数据结构的操作不需要去修改数据结构，也不必去修改原有的操作，从而执行时再定义新的Visitor实现者就行了。在Javac中不同的编译阶段都定义了不同的访问者模式实现。

## 三、Tomcat中的设计模式 ##

### 1、门面模式 ###

Tomcat中门面设计模式使用得很多，因为Tomcat中有很多组件，每个组件要相互交互数据，用门面设计模式隔离数据是个很好的方法。  
![这里写图片描述][20170810152643188]  
可以看到，HttpRequestFacade类封装了HttpRequest接口，能够提供数据，通过HttpRequestFacade访问到的数据被代理到HttpReauest中、通常被封装的对象都被设为Private或者Protectd的，防止在Facade中直接访问。

### 2、观察者模式 ###

Tomcat中观察者模式也有多处使用，前面讲的控制组件生命周期的Lifecycle就是这 种模式的体现，还有对Servlet实例的创建、Session的管理、Container等都是同样的原理。 下面主要看一下Lifecycle的具体实现。  
Lifecycle的观察者模式结构图如图所示。  
![这里写图片描述][20170810153501869]  
在上面的结构图中，LifecycleListener代表的是抽象观察者，它定义一个lifecycleEvent 方法，这个方法就是当主题变化时要执行的方法。ServerLifecycleListener代表的是具体的 观察者，它实现了 LifecycleListener接口的方法，就是这个具体的观察者具体的实现方式。 Lifecycle接口代表的是抽象主题，它定义了管理观察者的方法和它所要做的其他方法。而 StandardServer代表的是具体主题，它实现了抽象主题的所有方法。这里Tomcat对观察者 做了扩展，谓加了另外两个类：LifecycleSupport和LifecycleEvent，它们作为辅助类扩展 了观察者的功能。LifecycleEvent使得可以定义事件类别，不同的事件可区别处理，更加灵活。LifecycleSupport类代理了主题对多观察者的管理，将这个管理抽出来统一实现，以 后如采修改只要修改LifecycleSupport类就可以了，不需要去修改所有的具体主题，因为 所有具体主题对观察者的操作都被代理给LifecycleSupport类了。这可以认为是观察者模式的改进版。

### 3、命令设计模式 ###

Tomcat中命令模式在Connector和Container组件之间有体现，Tomcat作为一个应用 服务器，无疑会接收到很多请求，如何分配和执行这些请求是必须的功能。  
下面分析一下Tomcat是如何实现命令模式的，下图是Tomcat命令模式的结构图。  
![这里写图片描述][20170810153842940]  
Connector作为抽象请求者，HttpConnector作为具体请求者。HttpProcessor作为命令。 Container作为命令的抽象接受者，ContainerBase作为具体的接受者。客户端就是应用服务器Server组件了。Server首先创建命令请求者HttpConnector对象，然后创建命令 HttpProcessor对象。再把命令对象交给命令接受者ContainerBase容器来处理，命令最终是被Tomcat的Container执行的。命令可以以队列的方式进来，Container也可以以不同的 方式来处理请求，如HTTP1.0协议和HTTP1.1的处理方式就不同。

### 4、责任链模式 ###

Tomcat 中一个最容易发现的设计模式就是责任链设计模式，这个设计模式也是 Tomcat 中 Containe设计的基础，整个容器就是通过一个链连接在一起的，这个链一直将请求正确地传递给最终处理请求的那个 Servlet 。在Tomcat中这种设计模式儿乎被完整地使用，Tomcat的容器设置就是责任链模式，从Engine到Host再到Cortex，一直到Wrapper都通过这个链传递请求。  
![这里写图片描述][20170810154926474]

## 四、Spring中的设计模式 ##

### 1、简单工厂模式 ###

又叫做静态工厂方法（StaticFactory Method）模式，但不属于23种GOF设计模式之一。  
简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。  
spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。如下配置，就是在 HelloItxxz 类中创建一个 itxxzBean。

<beans>
        <bean id="singletonBean" class="com.kang.HelloItxxz">
            <constructor-arg>
                <value>Hello! 这是singletonBean!value>
            </constructor-arg>
       </ bean>
    
        <bean id="itxxzBean" class="com.kang.HelloItxxz"
            singleton="false">
            <constructor-arg>
                <value>Hello! 这是itxxzBean! value>
            </constructor-arg>
        </bean>
    
    </beans>

### 2、工厂方法模式 ###

通常由应用程序直接使用new创建新的对象，为了将对象的创建和使用相分离，采用工厂模式,即应用程序将对象的创建及初始化职责交给工厂对象。  
一般情况下,应用程序有自己的工厂对象来创建bean.如果将应用程序自己的工厂对象交给Spring管理,那么Spring管理的就不是普通的bean,而是工厂Bean。  
以工厂方法中的静态方法为例讲解一下：

import java.util.Random;
    public class StaticFactoryBean {
          public static Integer createRandom() {
               return new Integer(new Random().nextInt());
           }
    }

建一个config.xm配置文件，将其纳入Spring容器来管理,需要通过factory-method指定静态方法名称,createRandom方法必须是static的,才能找到

### 3、单例模式 ###

保证一个类仅有一个实例，并提供一个访问它的全局访问点。  
spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为spring管理的是是任意的java对象。 Spring下默认的bean均为singleton，可以通过singleton=“true|false” 或者 scope=“？”来指定

### 4、代理模式 ###

在Spring的Aop中，使用的Advice（通知）来增强被代理类的功能。Spring实现这一AOP功能的原理就使用代理模式（1、JDK动态代理。2、CGLib字节码生成技术代理。）对类进行方法级别的切面增强，即，生成被代理类的代理类， 并在代理类的方法前，设置拦截器，通过执行拦截器重的内容增强了代理方法的功能，实现的面向切面编程。

### 5、模板方法模式 ###

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。  
Template Method模式一般是需要继承的。这里想要探讨另一种对Template Method的理解。spring中的JdbcTemplate，在用这个类时并不想去继承这个类，因为这个类的方法太多，但是我们还是想用到JdbcTemplate已有的稳定的、公用的数据库连接，那么我们怎么办呢？我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码，而且这段代码会用到JdbcTemplate中的变量。怎么办？那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法，我们去实现这个方法，就把变化的东西集中到这里了。然后我们再传入这个回调对象到JdbcTemplate，从而完成了调用。这可能是Template Method不需要继承的另一种实现方式吧。

### 6、策略模式 ###

Spring中的策略模式使用多如牛毛，所谓策略模式就是定义了算法族，分别封装起来，让他们之前可以互相转换，此模式然该算法的变化独立于使用算法的客户。Spring的事务管理机制就是典型的策略模式，Spring事务策略是通过PlatformTransactionManager接口实现的，它是整个Spring事务的核心。它是对事务策略的一个高度抽象，不依赖于任何具体的事务策略，而对于底层的具体的事务策略它相应的有不同的实现类。而对于不同的事务策略的切换通常由Spring容器来负责管理，应用程序既无须与具体的事务API耦合，也无须与特定的实现类耦合而将应用和持久化技术，事务API彻底分离开来。

## 五、SpringMVC中的模板模式 ##

所谓模板模式就是定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。SpringMVC在保证整个框架流程稳定的情况下，预留很多口子，而这些口子都是所谓的模板方法，可以自由指定，从而保证了灵活性，接下来的很多使用最佳实践都是基于这种设计模式才可以实现。例如，下面的代码中doResolveException(..)就是一个口子，子类方法doResolveException(..)可以定义具体如何处理异常。

public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler,
            Exception ex) {
        if (shouldApplyTo(request, handler)) {
            logException(ex, request);
            prepareResponse(ex, response);
            return doResolveException(request, response, handler, ex);
        } else {
            return null;
        }
    }
    
    protected abstract ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response,
            Object handler, Exception ex);

[20170809172258274]: /images/20220611/a994ce06cf6a460c9338c0e0c724656a.png
[20170809171514383]: /images/20220611/847cd4877f784732a21c91b55e1c2c19.png
[20170810152643188]: /images/20220611/037a74ebd9de43aa9739d140ba426cdf.png
[20170810153501869]: /images/20220611/cab95f0c138c4025a158fce8cbf0617d.png
[20170810153842940]: /images/20220611/b5fd3167b803489390b21fd801fffb06.png
[20170810154926474]: /images/20220611/2f32094af6a44fd1bbf607a1f28d8321.png