设计模式十之适配器模式

最新推荐文章于 2024-06-13 20:29:08 发布
最新推荐文章于 2024-06-13 20:29:08 发布
阅读量86 收藏
点赞数
分类专栏： 设计模式 文章标签： 设计模式 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/pizicai007/article/details/105011257
版权

设计模式十之适配器模式

  在现实生活中，经常出现两个对象因接口不兼容而不能在一起工作的实例，这时需要第三者进行适配。例如，讲中文的人同讲英文的人对话时需要一个翻译，用直流电的笔记本电脑接交流电源时需要一个电源适配器，用计算机访问照相机的 SD 内存卡时需要一个读卡器等。
  在软件设计中也可能出现：需要开发的具有某种业务功能的组件在现有的组件库中已经存在，但它们与当前系统的接口规范不兼容，如果重新开发这些组件成本又很高，这时用适配器模式能很好地解决这些问题。

1. 模式的定义与特点

1.1 模式的定义

  适配器模式（Adapter）：将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的哪些类能一起工作。适配器模式分为类适配器模式和对象适配器模式，前者由继承实现，后者由组合实现。

1.2 模式的特点

  适配器模式的优点有：
    1. 能提高类的透明性和复用性，现有类复用但不需要改变；
    2. 目标类和适配器类解耦，提高程序扩展性；
    2. 符合开闭原则。

  适配器模式的缺点有：
    1. 适配器编写过程需要全面考虑，可能会增加系统的复杂性；
    2. 增加系统代码可读的难度。

1.3 模式的使用场景

  1. 已经存在的类，他的方法和需求不匹配；
  2. 不是软件设计阶段考虑的设计模式，是随着软件维护，由于不同产品，不同厂家造成功能类似而接口不相同情况下的解决方案。

2. 模式的结构与实现

  类的适配器模式可以采用多重继承的方式实现，但是由于 Java 不支持多继承，因此可以定义一个适配器类来实现当前系统的业务接口，同时又继承现有组件库中以ing存在的组件。
  对象的适配器模式可以采用将已有组件库中已实现的组件引入适配器中，该类同时实现当前系统的业务接口。

2.1 模式的结构

  适配器模式的主要角色如下：
    1. 目标接口（Target）：当前系统业务所期待的接口，可以是抽象类或是接口；
    2. 适配者类（Adaptee）：是被访问和等待适配的现存组件库中的组件接口；
    3. 适配器类（Adapter）：是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。
  下图分别是类的适配器模式和对象适配器模式的UML

类的适配器类UML

对象适配器类UML

2.2 模式的实现

类的适配器模式

/**
 * 目标类 - 接口
 */
public interface Target {

    void request();

}

/**
 * 具体目标类
 */
public class ConcreteTarget implements Target {

    @Override
    public void request() {
        System.out.println("ConcreteTarget 具体目标类的请求方法");
    }
}

/**
 * 适配者类
 */
public class Adaptee {

    public void adapteeRequest() {
        System.out.println("Adaptee 适配者类的请求方法");
    }
    
}

/**
 * 适配器类
 */
public class Adapter extends Adaptee implements Target {

    @Override
    public void request() {
        // ...
        super.adapteeRequest();
        // ...
    }

}

public class Client {

    public static void main(String[] args) {
        Target target = new ConcreteTarget();
        target.request();

        Target adapterTarget = new Adapter();
        adapterTarget.request();
    }

}

# 运行结果如下：
ConcreteTarget 集体目标类的请求方法
Adaptee 适配者的请求方法

对象适配器模式

/**
 * 目标类 - 接口
 */
public interface Target {

    void request();

}

/**
 * 具体目标类
 */
public class ConcreteTarget implements Target {

    @Override
    public void request() {
        System.out.println("ConcreteTarget 具体目标类的请求方法");
    }
}

/**
 * 适配者类
 */
public class Adaptee {

    public void adapteeRequest() {
        System.out.println("Adaptee 适配者类的请求方法");
    }
    
}

/**
 * 适配器类
 */
public class Adapter implements Target {

    private Adaptee adaptee = new Adaptee();

    @Override
    public void request() {
        // ...
        adaptee.adapteeRequest();
        // ...
    }

}

public class Client {

    public static void main(String[] args) {
        Target target = new ConcreteTarget();
        target.request();

        Target adapterTarget = new Adapter();
        adapterTarget.request();
    }

}

# 运行结果如下：
ConcreteTarget 集体目标类的请求方法
Adaptee 适配者的请求方法

  其实类的适配器模式的实现与对象的适配器模式的实现的唯一区别就是到底是继承适配者还是引入适配者而已。


3. 模式在开源软件中的应用

3.1 org.springframework.web.*.HandlerAdapter 类

public interface HandlerAdapter {

   boolean supports(Object handler);

   ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;

   long getLastModified(HttpServletRequest request, Object handler);

}

public class SimpleControllerHandlerAdapter implements HandlerAdapter {

   @Override
   public boolean supports(Object handler) {
      return (handler instanceof Controller);
   }

   @Override
   public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
         throws Exception {

      return ((Controller) handler).handleRequest(request, response);
   }

   @Override
   public long getLastModified(HttpServletRequest request, Object handler) {
      if (handler instanceof LastModified) {
         return ((LastModified) handler).getLastModified(request);
      }
      return -1L;
   }

}

public class HttpRequestHandlerAdapter implements HandlerAdapter {

   @Override
   public boolean supports(Object handler) {
      return (handler instanceof HttpRequestHandler);
   }

   @Override
   public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
         throws Exception {

      ((HttpRequestHandler) handler).handleRequest(request, response);
      return null;
   }

   @Override
   public long getLastModified(HttpServletRequest request, Object handler) {
      if (handler instanceof LastModified) {
         return ((LastModified) handler).getLastModified(request);
      }
      return -1L;
   }

}

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
   HttpServletRequest processedRequest = request;
   HandlerExecutionChain mappedHandler = null;
   boolean multipartRequestParsed = false;

   WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

   try {
      ModelAndView mv = null;
      Exception dispatchException = null;

      try {
         processedRequest = checkMultipart(request);
         multipartRequestParsed = processedRequest != request;

         // Determine handler for the current request.
         mappedHandler = getHandler(processedRequest);
         if (mappedHandler == null || mappedHandler.getHandler() == null) {
            noHandlerFound(processedRequest, response);
            return;
         }

         // Determine handler adapter for the current request.
         // 根据 mappedHandler 获取相应的 handler
         HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

         // Process last-modified header, if supported by the handler.
         String method = request.getMethod();
         boolean isGet = "GET".equals(method);
         if (isGet || "HEAD".equals(method)) {
            long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
            if (logger.isDebugEnabled()) {
               logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);
            }
            if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
               return;
            }
         }

         if (!mappedHandler.applyPreHandle(processedRequest, response)) {
            return;
         }

         try {
            // Actually invoke the handler.
            mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
         }
         finally {
            if (asyncManager.isConcurrentHandlingStarted()) {
               return;
            }
         }

         applyDefaultViewName(request, mv);
         mappedHandler.applyPostHandle(processedRequest, response, mv);
      }
      catch (Exception ex) {
         dispatchException = ex;
      }
      processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
   }
   catch (Exception ex) {
      triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
   }
   catch (Error err) {
      triggerAfterCompletionWithError(processedRequest, response, mappedHandler, err);
   }
   finally {
      if (asyncManager.isConcurrentHandlingStarted()) {
         // Instead of postHandle and afterCompletion
         mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
         return;
      }
      // Clean up any resources used by a multipart request.
      if (multipartRequestParsed) {
         cleanupMultipart(processedRequest);
      }
   }
}

/**
 * Return the HandlerAdapter for this handler object.
 * @param handler the handler object to find an adapter for
 * @throws ServletException if no HandlerAdapter can be found for the handler. This is a fatal error.
 */
protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
   for (HandlerAdapter ha : this.handlerAdapters) {
      if (logger.isTraceEnabled()) {
         logger.trace("Testing handler adapter [" + ha + "]");
      }
      if (ha.supports(handler)) {
         return ha;
      }
   }
   throw new ServletException("No adapter for handler [" + handler +
         "]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler");
}

  SpringMVC 中的适配器 HandlerAdapter，就是根据 Handler 规则执行不同的 Handler。
  DispatcherServlet 根据 HandlerMapping 返回的 handler，向 HandlerAdapter 发起请求，处理 handler。HandlerAdapter 根据规则找到对应的 handler 并让其执行，执行完毕后 Handler 会向 HandlerAdapter 返回一个 ModelAndView，最后由 HandlerAdapter 向 DispatcherServlet 返回一个 ModelAndView。
  HandlerAdapter 使得 Handler 的扩展变得容易，只需要增加一个新的 Handler 和一个对应的 HandlerAdapter 即可。因此 Spring 定义了一个适配接口，使得每一种 Controller 有一种对应的适配器实现类，让适配器代替 controller 执行相应的方法。这样在扩展 controller 时，只需要增加一个适配器类就完成了 Spring MVC 的扩展了。

坯子蔡
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
设计模式（十）适配器模式
xingjiarong的专栏
12-03 3253
一、问题引入说起适配器其实在我们的生活中是非常常见的，比如：如果你到日本出差，你会发现日本的插座电压都是110V的，而我们的手机充电器和笔记本充电器都是220V，所以你到了日本之后就没办法充电了，这时候我们通常会怎么办呢，当然是使用一个升压的变压器将电压升高到220V，这样我们的手机通过一个变压器（适配器）就能使用原本不能使用的插座了。又比如说，有的国家的插座都是三孔的，而我们的手机大部分都是两孔的
设计模式之适配器模式
flying_fish_wj的博客
11-22 231
适配器定义： 适配器模式将一个类的接口，转换成客户期望的另外一个接口。 使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作； 适配器的分类 1.组合的方式：采用组合的方式的适配器成为对象适配器 特点：把“把被适配者”作为一个对象组合到适配器类中，以修改目标接口包装被适配者 2.继承：采用继承方式的称为类适配器 特点：通过多重继承不兼容接口，实现对目标接口的匹配，单一的为某
设计模式之适配器模式(C++)
热门推荐
翟天保的博客
03-09 2万+
介绍设计模式之适配器模式
java设计模式之适配器模式
m0_47944994的博客
11-17 1961
java设计模式之适配器模式
设计模式学习之适配器模式
02-25
在我们平时的开发过程中，适配器模式可以说是经常能见到的设计模式，ListView和RecyclerView的Adapter就是典型的适配器模式，当我们在开发时，碰到要在两个完全没有关系的类之间进行交互，第一个解决方案是修改各自...
设计模式之 适配器 Adapter C++ 源码
09-22
设计模式之 适配器 Adapter C++ 源码 vs2019 工具，设计模式之 适配器 Adapter C++ 源码 vs2019 工具，设计模式之 适配器 Adapter C++ 源码 vs2019 工具，设计模式之 适配器 Adapter C++ 源码 vs2019 工具，设计模式...
设计模式之适配器模式.docx
09-28
设计模式
C++设计模式之适配器模式
01-20
生活中的适配器 买笔记本电脑，买手机时，都有一个电源适配器，电源适配器又叫外置电源，是小型便携式电子设备及电子电器的供电电压变换设备，常见于手机，笔记本电脑上。它的作用是将家里的220V高电压转换成这些...
C++中的单例模式
GOLOJO的博客
06-11 557
单例模式，通过确保类的唯一实例来简化资源管理，并在多个场景中广泛应用，如配置管理、日志记录和数据库连接池。
设计模式-建造者模式
Sun的个人博客
06-10 481
*** Description: 抽象的建造房屋的类*/// 打地基// 砌墙// 封顶// 造房子roofed();/*** Description: 产品*/
设计模式七大原则-接口隔离原则InterfaceSegregation
stan_ko的博客
06-10 272
类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口Interface1对于类A和类c来说不是最小接口，那么类B和类D必须去实现他们不需要的方法（造成浪费）。在项目中常见的业务类直接依赖另外一个业务类的时候往往也是违背接口隔离原则的，在实际项目中，出于开发速度、维护成本等原因，通常不会过于细化接口。按隔离原则应当这样处理:将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
【Rust】——面向对象设计模式的实现
shsjssnn的博客
06-08 2577
状态模式（state pattern）是一个面向对象设计模式。该模式的关键在于定义一系列值的内含状态。这些状态体现为一系列的状态对象，同时值的行为随着其内部状态而改变。我们将编写一个博客发布结构体的例子，它拥有一个包含其状态的字段，这是一个有着 "draft"、"review" 或 "published" 的状态对象 状态对象共享功能：当然，在 Rust 中使用结构体和 trait 而不是对象和继承。每一个状态对象负责其自身的行为，以及该状态何时应当转移至另一个状态。持有一个状态对象的
简单工厂模式(大话设计模式)C/C++版本
m0_47104421的博客
06-13 125
参考：https://www.cnblogs.com/Galesaur-wcy/p/15926669.html。
设计模式之单例模式
m0_61990249的博客
06-13 697
单例模式：恶汉模式、懒汉模式、线程安全
设计模式七大原则-单一职责原则SingleResponsibility
stan_ko的博客
06-10 342
七大原则是在设计“设计模式”的时候需要用到的原则，它们的存在是为了保证设计模式达到以下几种目的：1.代码重用性2.可读性3.可拓展性4.可靠性（增加新的功能后，对原来的功能没有影响）5.使程序呈现高内聚、低耦合的特性。
策略模式（设计模式）
刘皇叔说Java的博客
06-13 721
使用策略模式重构 if/else策略设计模式是一种允许在运行时选择算法的行为。这种模式● 定义了一系列算法● 封装每种算法● 使算法在该系列内可互换。下面是策略设计模式的架构，客户端将在其中与上下文进行通信。上下文将包含对策略对象的引用，这反映了另一个设计原则 “针对接口而非实现编程”。策略模式是指有一定行动内容的相对稳定的策略名称，策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。
仲恺ZK——信计专业《软件体系结构》24年试卷回忆
最新发布
qq_65034569的博客
06-13 414
以下是我在总结的复习内容，有需要可以参考借鉴一下。我的主页还有另外一篇复习总结，两者结合起来复习，帮助你轻松过考试😊。总的来说，考试不会太难，只要你了解了各类设计模式的含义即可（真的就是了解即可，能从含义确认出是什么设计模式就👌了。不需要学会默写，因为考试的时候这么多选择题选项可以参考😄。如果需要资料的话可以私信我，我通过邮箱📮发送给各位💪。资料总结也有错误❎，欢迎大家批评指正👏。
手撕设计模式——计划生育之单例模式
love_spinach的博客
06-12 863
​你真的完全了解单例模式吗？菠菜带你手撕面试官。
设计模式的适配器模式
10-20
适配器模式是一种结构型设计模式，它的主要作用是将一个接口转换成另一个接口，以便不同的接口之间可以兼容并能够正常工作。通常情况下，我们使用适配器模式来重用现有的代码或者集成老系统，并且不需要修改其原有的代码。适配器模式主要由三个角色组成：目标接口（target）、源对象（source）和适配器对象（adapter）。目标接口是需要适配的标准接口，源对象是需要被适配的不兼容对象，适配器对象则充当中间转换角色，将源对象转换成目标接口。适配器模式可以帮助我们解决在不改变现有代码的情况下，使不兼容的接口之间能够正常工作的问题。但是，适配器模式也有一些缺点，例如会导致系统的复杂性增加，而且在应用过程中需要谨慎选择适配器的类型和实现方式。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值