適配器模式的概念是將一個(gè)類的接口轉(zhuǎn)換成客戶欲望的別的一個(gè)接口，使得本來因?yàn)榻涌诓患嫒荻豢瞬患耙宦饭ぷ鞯哪切╊惪梢砸宦饭ぷ?。適配就是大年夜“源”到“目標(biāo)”的適配，而中心鏈接“源”和“目標(biāo)”的就是適配器。
       適配器一共涉及三種角色，分別是：1.目標(biāo)接口(Target)，即客戶所期望的接口，目標(biāo)可所以具體或者抽象的類，也可所以接口；2.須要適配的類(Adaptee)；3.適配器(Adapter):經(jīng)由過程包裝一個(gè)須要適配的對(duì)象，將原接口轉(zhuǎn)化成目標(biāo)接口。
       舉個(gè)簡(jiǎn)單例子來解釋適配器模式：有一個(gè)"源"（Adaptee）是一小我，他會(huì)說日語和英語，但某個(gè)崗?fù)?Target)須要的是既會(huì)日語，又要懂英語，還得懂法語，這時(shí)就須要我們添加一個(gè)說法語的辦法，才能使該"源"（Adaptee）勝任這個(gè)崗?fù)?Target)。那么具體該若何操作呢？一種辦法是直接修改"源"（Adaptee），給他添加一個(gè)說法語的辦法，但如許真的合適嗎？適配是為了實(shí)現(xiàn)某種目標(biāo)而臨時(shí)性的為"源"（Adaptee）添加上某種辦法，所以不克不及修改"源"（Adaptee），并且一旦修改，就違背了java高內(nèi)聚低耦合的特點(diǎn)。那么畢竟如何才能實(shí)現(xiàn)既添加辦法，又不違背java高內(nèi)聚低耦合的特點(diǎn)呢？
源代碼如下：

public class Moluo {
	
	private String name;
	private String sex;
	private int age;
	
	public void speakJapanese(){
		System.out.println("I can speak Japanese!");
	}
	
	public void speakEnglish(){
		System.out.println("I can speak English!");
	}
	...//以下省略成員變量的get和set辦法
}

目標(biāo)接口代碼如下：

public interface Job {
	
	public abstract void speakJapanese();
	public abstract void speakEnglish();
	public abstract void speakFrench();
	
}

適配器代碼如下：

public class Adapter extends Moluo implements Job{

	public void speakFrench() {
		
	}
	
}

       噢啦，經(jīng)由過程適配器模式，摩羅就成了精曉三門外語的人才了，再也不消受六級(jí)的困擾了，想想都沖動(dòng)....
      其實(shí)，適配器模式有兩種，一種是類適配器，別的一種是對(duì)象適配器。上述辦法其實(shí)就是類適配器。因?yàn)閖ava不支撐多持續(xù)，只能單持續(xù)，所以一般類適配器用得就比較少，因?yàn)榫窒扌员饶_綾趨顯，比如一個(gè)目標(biāo)接口同時(shí)須要多個(gè)"源"（Adaptee），顯然類適配器明顯不克不及實(shí)現(xiàn)，所以就須要采取對(duì)象適配器來實(shí)現(xiàn)。
      源代碼和目標(biāo)接口代碼同上，不再贅述，下面是適配器代碼：

public class Adapter implements Job {

	Moluo moluo;

	public Adapter(Moluo moluo) {
		this.moluo = moluo;
	}

	public void speakEnglish() {
		moluo.speakEnglish();
	}

	public void speakJapanese() {
		moluo.speakJapanese();
	}

	//new add
	public void speakFrench() {
		
	}

}

        扼要分析一下上述兩種適配器模式，類的適配模式用于單一源的適配，因?yàn)樗脑吹膯我辉?，代碼實(shí)現(xiàn)不消寫選擇邏輯，很清楚；而對(duì)象的適配模式則可用于多源的適配，彌補(bǔ)潦攀類適配模式的不足，使得本來用類適配模式須要寫很多適配器的情況不復(fù)存在，弱點(diǎn)是，因?yàn)樵吹臄?shù)量可以較多，所以具體的實(shí)現(xiàn)前提選擇分支比較多，不太清楚。    
 最后總結(jié)一下適配器模式：
  長(zhǎng)處：
      1.復(fù)竽暌姑了現(xiàn)存的類，解決了現(xiàn)存類和復(fù)竽暌姑情況請(qǐng)求不一致的問題。
      2.將目標(biāo)類和適拍┞憤類解耦，經(jīng)由過程惹人一個(gè)適配拼蕩蜇用現(xiàn)有的適拍┞憤類，而無需修改原有代碼。
      3.一個(gè)對(duì)象適配器可以把多個(gè)不合的適拍┞憤類適配到同一個(gè)目標(biāo)，也就是說，同一個(gè)適配器可以把適拍┞憤類和它的子類都適配到目標(biāo)接口。
  缺點(diǎn)： 對(duì)于對(duì)象適配器來說，改換適配器的實(shí)現(xiàn)過程比較復(fù)雜。
  實(shí)用處景：
             1. 體系須要應(yīng)用現(xiàn)有的類，而這些類的接口不相符體系的接口。
     2. 想要建立一個(gè)可以重用的類，用于與一些彼此之間沒有太大年夜接洽關(guān)系的一些類，包含一些可能在將來引進(jìn)的類一路工作。
             3.兩個(gè)類所做的工作雷同或相似，然則具有不合接口的時(shí)刻。
     4.舊的體系開辟的類已經(jīng)實(shí)現(xiàn)了一些功能，然則客戶端卻只能以別的接口的情勢(shì)拜訪，但我們不欲望手動(dòng)更改原有類的時(shí)刻。
     5.應(yīng)用第三方組件，組件接口定義和本身定義的不合，不欲望修改本身的接口，然則要應(yīng)用第三方組件接口的功能。

尊再版權(quán)，轉(zhuǎn)載請(qǐng)注明本文鏈接
                                      
                                           迎接存眷行者摩羅微信"大眾,"號(hào)(xingzhemoluo)，合營(yíng)交換編程經(jīng)驗(yàn)，掃描下方二維碼即可;    
                                                                  [img]http://img.blog.csdn.net/20150105230410875