我欲封天txt下载,小说阅读网站

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

項(xiàng)目升級(jí)后如何兼容舊接口？試試適配器模式吧！

前言

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

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

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

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

原理很簡(jiǎn)單，我們?cè)賮?lái)看下它的代碼實(shí)現(xiàn)。

適配器模式有兩種實(shí)現(xiàn)方式：類適配器和對(duì)象適配器。其中，類適配器使用繼承關(guān)系來(lái)實(shí)現(xiàn)，對(duì)象適配器使用組合關(guān)系來(lái)實(shí)現(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() {
  //...重新實(shí)現(xiàn)f2()...
 }
 // 這里fc()不需要實(shí)現(xiàn)，直接繼承自Adaptee，這是跟對(duì)象適配器最大的不同點(diǎn)
}
// 對(duì)象適配器：基于組合
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() {
  //...重新實(shí)現(xiàn)f2()...
 } 
 public void fc() {
  adaptee.fc();
 }
}

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

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

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

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

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

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

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

舉個(gè)例子：

public class CD { //這個(gè)類來(lái)自外部sdk，我們無(wú)權(quán)修改它的代碼
 //...
 public static void staticFunction1() { //... }
 public void uglyNamingFunction2() { //... }
 public void tooManyParamsFunction3(int paramA, int paramB, ...) { //... }
 public void lowPerformanceFunction4() { //... }
}
// 使用適配器模式進(jìn)行重構(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)一多個(gè)類的接口設(shè)計(jì)

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

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

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

public class ASensitiveWordsFilter { // A敏感詞過(guò)濾系統(tǒng)提供的接口
 //text是原始文本，函數(shù)輸出用***替換敏感詞之后的文本
 public String filterSexyWords(String text) {
 // ...
 }
 public String filterPoliticalWords(String text) {
 // ...
 }
}
public class BSensitiveWordsFilter { // B敏感詞過(guò)濾系統(tǒng)提供的接口
 public String filter(String text) {
 //...
 }
}
public class CSensitiveWordsFilter { // C敏感詞過(guò)濾系統(tǒng)提供的接口
 public String filter(String text, String mask) {
 //...
 }
}
// 未使用適配器模式之前的代碼：代碼的可測(cè)試性、擴(kuò)展性不好
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;
 }
}
// 使用適配器模式進(jìn)行改造
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...
// 擴(kuò)展性更好，更加符合開(kāi)閉原則，如果添加一個(gè)新的敏感詞過(guò)濾系統(tǒng)，
// 這個(gè)類完全不需要改動(dòng)；而且基于接口而非實(shí)現(xiàn)編程，代碼的可測(cè)試性更好。
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)

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

// 外部系統(tǒng)A
public interface IA {
 //...
 void fa();
}
public class A implements IA {
 //...
 public void fa() { //... }
}
// 在我們的項(xiàng)目中，外部系統(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接口的地方都無(wú)需改動(dòng)，
// 只需要將BAdaptor如下注入到Demo即可。
Demo d = new Demo(new BAdaptor(new B()));

兼容老版本接口

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

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

單獨(dú)一個(gè)項(xiàng)目做 Enumeration 到 Iterator 的替換，勉強(qiáng)還能接受。但是，使用 Java 開(kāi)發(fā)的項(xiàng)目太多了，一次 JDK 的升級(jí)，導(dǎo)致所有的項(xiàng)目不做代碼修改就會(huì)編譯報(bào)錯(cuò)，這顯然是不合理的。這就是我們經(jīng)常所說(shuō)的不兼容升級(jí)。為了做到兼容使用低版本 JDK 的老代碼，我們可以暫時(shí)保留 Enumeration 類，并將其實(shí)現(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)一為相同的格式，以方便存儲(chǔ)和使用。比如Java 中的 Arrays.asList() 也可以看作一種數(shù)據(jù)適配器，將數(shù)組類型的數(shù)據(jù)轉(zhuǎn)化為集合容器類型。

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

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

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

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

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

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

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

不僅如此，Slf4j 的出現(xiàn)晚于 JUL、JCL、log4j 等日志框架，所以，這些日志框架也不可犧牲掉版本兼容性，將接口改造成符合 Slf4j 接口規(guī)范。Slf4j 也事先考慮到了這個(gè)問(wèn)題，所以它不僅僅提供了統(tǒng)一的接口定義，還提供了針對(duì)不同日志框架的適配器，對(duì)不同的日志框架的接口進(jìn)行了二次封裝，適配成統(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實(shí)現(xiàn)了LocationAwareLogger接口，
// 其中LocationAwareLogger繼承自Logger接口，
// 也就相當(dāng)于Log4jLoggerAdapter實(shí)現(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);
 }
 //...省略一堆接口的實(shí)現(xiàn)...
}

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

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

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

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

代理模式：代理模式在不改變?cè)碱惤涌诘臈l件下，為原始類定義一個(gè)代理類，主要目的是控制訪問(wèn)，而非加強(qiáng)功能。這是它跟裝飾器模式最大的不同。
橋接模式：橋接模式的目的是將接口部分和實(shí)現(xiàn)部分分離，從而讓它們可以更加容易、也相對(duì)獨(dú)立的加以改變。
裝飾器模式：裝飾器模式在不改變?cè)碱惤涌诘那闆r下，對(duì)原始類功能進(jìn)行增強(qiáng)，并且支持多個(gè)裝飾器模式的嵌套使用。
適配器模式：適配器模式是一種事后的補(bǔ)救策略。適配器提供跟原始類不同的接口，而代理模式、裝飾器模式提供的都是跟原始類相同的接口。

總結(jié)

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

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

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

網(wǎng)站欄目：項(xiàng)目升級(jí)后如何兼容舊接口？試試適配器模式吧！
文章分享：http://m.fisionsoft.com.cn/article/dpjssjh.html