日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
項目升級后如何兼容舊接口？試試適配器模式吧！

前言

適配器模式的英文翻譯是 Adapter Design Pattern。顧名思義，這個模式就是用來做適配的，它將不兼容的接口轉(zhuǎn)換為可兼容的接口，讓原本由于接口不兼容而不能一起工作的類可以一起工作。

創(chuàng)新互聯(lián)專注于企業(yè)成都全網(wǎng)營銷、網(wǎng)站重做改版、商都網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、HTML5建站、商城網(wǎng)站建設(shè)、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為商都等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

對于這個模式，有一個經(jīng)常被拿來解釋它的例子，就是USB轉(zhuǎn)接頭充當適配器，把兩種不兼容的接口，通過轉(zhuǎn)接變得可以一起工作。

適配器模式的原理與實現(xiàn)

原理很簡單，我們再來看下它的代碼實現(xiàn)。

適配器模式有兩種實現(xiàn)方式：類適配器和對象適配器。其中，類適配器使用繼承關(guān)系來實現(xiàn)，對象適配器使用組合關(guān)系來實現(xiàn)。

具體代碼如下。其中，其中，ITarget 表示要轉(zhuǎn)化成的接口定義。Adaptee 是一組不兼容 ITarget接口定義的接口，Adaptor 將 Adaptee 轉(zhuǎn)化成一組符合 ITarget 接口定義的接口。

// 類適配器: 基于繼承
public interface ITarget {
 void f1();
 void f2();
 void fc();
}
public class Adaptee {
 public void fa() { ... }
 public void fb() { ... }
 public void fc() { ... }
}
public class Adaptor extends Adaptee implements ITarget {
 public void f1() {
  super.fa();
 }
 public void f2() {
  //...重新實現(xiàn)f2()...
 }
 // 這里fc()不需要實現(xiàn)，直接繼承自Adaptee，這是跟對象適配器最大的不同點
}
// 對象適配器：基于組合
public interface ITarget {
 void f1();
 void f2();
 void fc();
}
public class Adaptee {
 public void fa() { ... }
 public void fb() { ... }
 public void fc() { ... }
}
public class Adaptor implements ITarget {
 private Adaptee adaptee;
 public Adaptor(Adaptee adaptee) {
  this.adaptee = adaptee;
 } 
 public void f1() {
  adaptee.fa(); //委托給Adaptee
 } 
 public void f2() {
  //...重新實現(xiàn)f2()...
 } 
 public void fc() {
  adaptee.fc();
 }
}

針對這兩種實現(xiàn)方式，在實際開發(fā)中，到底該選擇哪一種呢?判斷的標準主要有兩個，一個是Adaptee接口的個數(shù)，另一個是Adaptee和ITarget的契合程度：

  • 如果Adaptee接口并不多，那兩種實現(xiàn)方式都可以。
  • 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定義大部分都相同，那我們推薦使用類適配器，因為 Adaptor 復(fù)用父類 Adaptee 的接口，比起對象適配器的實現(xiàn)方式，Adaptor 的代碼量要少一些。
  • 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定義大部分都不相同，那我們推薦使用對象適配器，因為組合結(jié)構(gòu)相對于繼承更加靈活。

適配器模式應(yīng)用場景總結(jié)

一般來說，適配器模式可以看作一種“補償模式”，用來補救設(shè)計上的缺陷。應(yīng)用這種模式算是“無奈之舉”。如果在設(shè)計初期，我們就能協(xié)調(diào)規(guī)避接口不兼容的問題，那這種模式就沒有應(yīng)用的機會了。

適配器模式的應(yīng)用場景是“接口不兼容”。那在實際的開發(fā)中，什么情況下才會出現(xiàn)接口不兼容呢?

封裝有缺陷的接口設(shè)計

假設(shè)我們依賴的外部系統(tǒng)在接口設(shè)計上有缺陷(比如包含大量靜態(tài)方法)，引入之后會影響到我們自身代碼的可測試性。為了隔離設(shè)計上的缺陷，我們希望對外部系統(tǒng)提供的接口進行二次封裝，抽象出更好的接口設(shè)計，這個時候就可以使用適配器模式了。

舉個例子：

public class CD { //這個類來自外部sdk，我們無權(quán)修改它的代碼
 //...
 public static void staticFunction1() { //... }
 public void uglyNamingFunction2() { //... }
 public void tooManyParamsFunction3(int paramA, int paramB, ...) { //... }
 public void lowPerformanceFunction4() { //... }
}
// 使用適配器模式進行重構(gòu)
public class ITarget {
 void function1();
 void function2();
 void fucntion3(ParamsWrapperDefinition paramsWrapper);
 void function4();
 //...
}
// 注意：適配器類的命名不一定非得末尾帶Adaptor
public class CDAdaptor extends CD implements ITarget { 
 //...
 public void function1() {
  super.staticFunction1();
 }
 public void function2() {
  super.uglyNamingFucntion2();
 }
 public void function3(ParamsWrapperDefinition paramsWrapper) {
  super.tooManyParamsFunction3(paramsWrapper.getParamA(), ...);
 } 
 public void function4() {
  //...reimplement it...
 }
}

統(tǒng)一多個類的接口設(shè)計

某個功能的實現(xiàn)依賴多個外部系統(tǒng)(或者說類)。通過適配器模式，將它們的接口適配為統(tǒng)一的接口定義，然后我們就可以使用多態(tài)的特性來復(fù)用代碼邏輯。

舉個例子：假設(shè)我們的系統(tǒng)要對用戶輸出的文本內(nèi)容做敏感詞過濾，為了提高過濾的召回率，我們引入了多個第三方敏感詞過濾系統(tǒng)，依次對用戶輸入的內(nèi)容進行過濾，過濾掉盡可能多的敏感詞。但是，每個系統(tǒng)提供的過濾接口都是不同的，這就意味著我們沒法復(fù)用一套邏輯來調(diào)用各個系統(tǒng)。

這個時候，我們可以用適配器模式，將所有系統(tǒng)的接口適配為統(tǒng)一的接口定義，這樣我們可以復(fù)用調(diào)用敏感詞過濾的代碼：

public class ASensitiveWordsFilter { // A敏感詞過濾系統(tǒng)提供的接口
 //text是原始文本，函數(shù)輸出用***替換敏感詞之后的文本
 public String filterSexyWords(String text) {
 // ...
 }
 public String filterPoliticalWords(String text) {
 // ...
 }
}
public class BSensitiveWordsFilter { // B敏感詞過濾系統(tǒng)提供的接口
 public String filter(String text) {
 //...
 }
}
public class CSensitiveWordsFilter { // C敏感詞過濾系統(tǒng)提供的接口
 public String filter(String text, String mask) {
 //...
 }
}
// 未使用適配器模式之前的代碼：代碼的可測試性、擴展性不好
public class RiskManagement {
 private ASensitiveWordsFilter aFilter = new ASensitiveWordsFilter();
 private BSensitiveWordsFilter bFilter = new BSensitiveWordsFilter();
 private CSensitiveWordsFilter cFilter = new CSensitiveWordsFilter();
 public String filterSensitiveWords(String text) {
  String maskedText = aFilter.filterSexyWords(text);
  maskedText = aFilter.filterPoliticalWords(maskedText);
  maskedText = bFilter.filter(maskedText);
  maskedText = cFilter.filter(maskedText, "***");
  return maskedText;
 }
}
// 使用適配器模式進行改造
public interface ISensitiveWordsFilter { // 統(tǒng)一接口定義
 String filter(String text);
}
public class ASensitiveWordsFilterAdaptor implements ISensitiveWordsFilter {
 private ASensitiveWordsFilter aFilter; 
 public String filter(String text) {
  String maskedText = aFilter.filterSexyWords(text);
  maskedText = aFilter.filterPoliticalWords(maskedText);
  return maskedText;
 }
}
//...省略BSensitiveWordsFilterAdaptor、CSensitiveWordsFilterAdaptor...
// 擴展性更好，更加符合開閉原則，如果添加一個新的敏感詞過濾系統(tǒng)，
// 這個類完全不需要改動；而且基于接口而非實現(xiàn)編程，代碼的可測試性更好。
public class RiskManagement {
 private List filters = new ArrayList<>();
 public void addSensitiveWordsFilter(ISensitiveWordsFilter filter) {
  filters.add(filter);
 }
 public String filterSensitiveWords(String text) {
  String maskedText = text;
  for (ISensitiveWordsFilter filter : filters) {
   maskedText = filter.filter(maskedText);
  }
  return maskedText;
 }
}

替換依賴的外部系統(tǒng)

當我們把項目中依賴的一個外部系統(tǒng)替換為另一個外部系統(tǒng)的時候，利用適配器模式，可以減少對代碼的改動。如下：

// 外部系統(tǒng)A
public interface IA {
 //...
 void fa();
}
public class A implements IA {
 //...
 public void fa() { //... }
}
// 在我們的項目中，外部系統(tǒng)A的使用示例
public class Demo {
 private IA a;
 
 public Demo(IA a) {
  this.a = a;
 }
 //...
}
Demo d = new Demo(new A());
// 將外部系統(tǒng)A替換成外部系統(tǒng)B
public class BAdaptor implemnts IA {
 private B b;
 public BAdaptor(B b) {
  this.b= b;
 }
 public void fa() {
  //...
  b.fb();
 }
}
// 借助BAdaptor，Demo的代碼中，調(diào)用IA接口的地方都無需改動，
// 只需要將BAdaptor如下注入到Demo即可。
Demo d = new Demo(new BAdaptor(new B()));

兼容老版本接口

在做版本升級的時候，對于一些要廢棄的接口，我們不直接將其刪除，而是暫時保留，并且標注為 deprecated，并將內(nèi)部實現(xiàn)邏輯委托為新的接口實現(xiàn)。這樣做的好處是，讓使用它的項目有個過渡期，而不是強制進行代碼修改。這也可以粗略地看作適配器模式的一個應(yīng)用場景。

舉個例子：JDK1.0 中包含一個遍歷集合容器的類 Enumeration。JDK2.0 對這個類進行了重構(gòu)，將它改名為 Iterator 類，并且對它的代碼實現(xiàn)做了優(yōu)化。但是考慮到如果將 Enumeration 直接從 JDK2.0 中刪除，那使用 JDK1.0 的項目如果切換到 JDK2.0，代碼就會編譯不通過。為了避免這種情況的發(fā)生，我們必須把項目中所有使用到 Enumeration 的地方，都修改為使用 Iterator 才行。

單獨一個項目做 Enumeration 到 Iterator 的替換，勉強還能接受。但是，使用 Java 開發(fā)的項目太多了，一次 JDK 的升級，導(dǎo)致所有的項目不做代碼修改就會編譯報錯，這顯然是不合理的。這就是我們經(jīng)常所說的不兼容升級。為了做到兼容使用低版本 JDK 的老代碼，我們可以暫時保留 Enumeration 類，并將其實現(xiàn)替換為直接調(diào)用 Itertor。

代碼示例如下所示：

public class Collections {
public static Emueration emumeration(final Collection c) {
 return new Enumeration() {
  Iterator i = c.iterator();  
  public boolean hasMoreElments() {
   return i.hashNext();
  }  
  public Object nextElement() {
   return i.next():
  }
 }
  }
}

適配不同格式的數(shù)據(jù)

適配器模式除了可以用于接口的適配外，還可以用在不同格式的數(shù)據(jù)間的適配。比如，把從不同征信系統(tǒng)拉取不同格式的征信數(shù)據(jù)，統(tǒng)一為相同的格式，以方便存儲和使用。比如Java 中的 Arrays.asList() 也可以看作一種數(shù)據(jù)適配器，將數(shù)組類型的數(shù)據(jù)轉(zhuǎn)化為集合容器類型。

List stooges = Arrays.asList("Larry", "Moe", "Curly")

剖析適配器模式在 Java 日志中的應(yīng)用

Java中有很多日志框架，在項目開發(fā)中，我們常用它們來打印日志信息。其中，比較常用的有 log4j、logback，以及 JDK 提供的 JUL(java.util.logging) 和 Apache 的JCL(Jakarta Commons Logging) 等。

大部分日志框架都提供了相似的功能，比如按照不同級別(debug、info、warn、erro……)打印日志等，但它們并沒有實現(xiàn)統(tǒng)一的接口。這主要可能是歷史原因，它不想JDBC那樣，一開始就制定了數(shù)據(jù)庫操作的接口規(guī)范。

如果我們只是開發(fā)一個自己用的項目，那什么日志框架都可以。但是如果我們開發(fā)的是一個集成到其他系統(tǒng)的組件、框架、類庫等，那日志框架的選擇就沒有那么隨意了。

比如，項目中用到的某個組件使用 log4j 來打印日志，而我們項目本身使用的是logback。將組件引入到項目中之后，我們的項目就相當于有兩套日志打印框架。每種日志框架都有自己特有的配置方式。所以，我們要針對每種日志框架編寫不同的配置文件(比如，日志存儲的文件地址、打印日志的格式)。如果引入多個組件，每個組件使用的日志框架都不一樣，那日志本身的管理工作就變得非常復(fù)雜。所以，為了解決這個問題，我們需要同一日志打印框架。

java中的Slf4j 這個日志框架就相當于 JDBC 規(guī)范，提供了一套打印日志的統(tǒng)一接口規(guī)范。不過，它只定義了接口，并沒有提供具體的實現(xiàn)，需要配合其他日志框架架(log4j、logback……)來使用。

不僅如此，Slf4j 的出現(xiàn)晚于 JUL、JCL、log4j 等日志框架，所以，這些日志框架也不可犧牲掉版本兼容性，將接口改造成符合 Slf4j 接口規(guī)范。Slf4j 也事先考慮到了這個問題，所以它不僅僅提供了統(tǒng)一的接口定義，還提供了針對不同日志框架的適配器，對不同的日志框架的接口進行了二次封裝，適配成統(tǒng)一的Slf4j接口定義。具體代碼如下：

 // slf4j統(tǒng)一的接口定
package org.slf4j;
public interface Logger {
 public boolean isTraceEnabled();
 public void trace(String msg);
 public void trace(String format, Object arg);
 public void trace(String format, Object arg1, Object arg2);
 public void trace(String format, Object[] argArray);
 public void trace(String msg, Throwable t);
 public boolean isDebugEnabled();
 public void debug(String msg);
 public void debug(String format, Object arg);
 public void debug(String format, Object arg1, Object arg2)
 public void debug(String format, Object[] argArray)
 public void debug(String msg, Throwable t);
 //...省略info、warn、error等一堆接口
}
// log4j日志框架的適配器
// Log4jLoggerAdapter實現(xiàn)了LocationAwareLogger接口，
// 其中LocationAwareLogger繼承自Logger接口，
// 也就相當于Log4jLoggerAdapter實現(xiàn)了Logger接口。
package org.slf4j.impl;
public final class Log4jLoggerAdapter extends MarkerIgnoringBase implements LocationAwareLogger, Serializable {
 final transient org.apache.log4j.Logger logger; // log4j 
 public boolean isDebugEnabled() {
  return logger.isDebugEnabled();
 }
 public void debug(String msg) {
  logger.log(FQCN, Level.DEBUG, msg, null);
 } 
 public void debug(String format, Object arg) {
  if (logger.isDebugEnabled()) {
   FormattingTuple ft = MessageFormatter.format(format, arg);
   logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable());
  }
 } 
 public void debug(String format, Object arg1, Object arg2) {
  if (logger.isDebugEnabled()) {
   FormattingTuple ft = MessageFormatter.format(format, arg1, arg2);
   logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable());
  }
 }
 public void debug(String format, Object[] argArray) {
  if (logger.isDebugEnabled()) {
   FormattingTuple ft = MessageFormatter.arrayFormat(format, argArray);
   logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable());
  }
 } 
 public void debug(String msg, Throwable t) {
  logger.log(FQCN, Level.DEBUG, msg, t);
 }
 //...省略一堆接口的實現(xiàn)...
}

所以，在開發(fā)業(yè)務(wù)系統(tǒng)或者開發(fā)框架、組件的時候，我們統(tǒng)一使用 Slf4j 提供的接口來編寫打印日志的代碼，具體使用哪種日志框架實現(xiàn)(log4j、logback……)，是可以動態(tài)地指定的，只需要將相應(yīng)的 SDK 導(dǎo)入到項目中即可。

代理、橋接、裝飾器、適配器 4 種設(shè)計模式的區(qū)別

代理、橋接、裝飾器、適配器，這 4 種模式是比較常用的結(jié)構(gòu)型設(shè)計模式。它們的代碼結(jié)構(gòu)非常相似?；\統(tǒng)來說，它們都可以稱為 Wrapper 模式，也就是通過 Wrapper 類二次封裝原始類。

盡管代碼結(jié)構(gòu)相似，但這 4 種設(shè)計模式的用意完全不同，也就是說要解決的問題、應(yīng)用場景不同，這也是它們的主要區(qū)別。

  • 代理模式：代理模式在不改變原始類接口的條件下，為原始類定義一個代理類，主要目的是控制訪問，而非加強功能。這是它跟裝飾器模式最大的不同。
  • 橋接模式：橋接模式的目的是將接口部分和實現(xiàn)部分分離，從而讓它們可以更加容易、也相對獨立的加以改變。
  • 裝飾器模式：裝飾器模式在不改變原始類接口的情況下，對原始類功能進行增強，并且支持多個裝飾器模式的嵌套使用。
  • 適配器模式：適配器模式是一種事后的補救策略。適配器提供跟原始類不同的接口，而代理模式、裝飾器模式提供的都是跟原始類相同的接口。

總結(jié)

適配器模式是用來做適配，它將不兼容的接口轉(zhuǎn)換為可兼容的接口，讓原本由于接口不兼容而不能一起工作的類可以一起工作。適配器模式有兩種實現(xiàn)方式：類適配器和對象適配器。其中，類適配器使用繼承關(guān)系來實現(xiàn)，對象適配器使用組合關(guān)系來實現(xiàn)。

一般來說，適配器模式可以看作一種“補償模式”，用來補救設(shè)計上的缺陷。應(yīng)用這種模式算是“無奈之舉”，如果在設(shè)計初期，我們就能協(xié)調(diào)規(guī)避接口不兼容的問題，那這種模式就沒有應(yīng)用的機會了。那在實際的開發(fā)中，什么情況下才會出現(xiàn)接口不兼容呢?

  • 封裝有缺陷的接口設(shè)計。
  • 統(tǒng)一多個類的接口設(shè)計。
  • 替換依賴的外部系統(tǒng)。
  • 兼容老版本接口。
  • 適配不同格式的數(shù)據(jù)。

分享題目：項目升級后如何兼容舊接口？試試適配器模式吧！
鏈接地址：http://www.dlmjj.cn/article/dpjssjh.html