適配器模式和外觀模式

適配器模式:

將一個類的接口，轉換成客戶指望的另外一個接口。適配器讓本來不兼容的類能夠合做無間。

例子:

//將Enumeration轉換成Iterator
public class EnumerationIterator implements Iterator{

	Enumeration enum;

	public EnumerationIterator(Enumeration enum){
		this.enum = enum;
	}

	public boolean hasNext(){
		return enum.hasMoreElements();
	}

	public Object next(){
		return enum.nextElement();
	}

	public void remove(){
		throw new UnsupportedOperationException();
	}
}

外觀模式提供了一個統一的接口，用來訪問子系統中的一羣接口。外觀定義了一個高層接口，讓子系統更容易使用

外觀模式之"最少知識"原則

設計原則:

最少知識原則：只和你的密友談話。這個原則但願咱們在設計中，不要讓太多的類耦合在一塊兒，省得修改系統中一部分，會影響到其餘部分。若是許多類之間相互依賴，那麼這個系統就會變成一個易碎的系統，它須要花許多成本維護，也會由於太複雜而不容易被其餘人瞭解。

墨忒(tui第一聲)耳法則:

墨忒耳法則和最少知識原則的關係:

兩個名詞指的是同一個原則。咱們傾向於使用最少知識原則來稱呼它是由於如下兩個緣由:(1)這個名字更加直接。(2)法則(Law)給人的感受是強制的。事實上，沒有任何原則是法律,全部原則都應該在有幫助的時候才遵照。搜友的設計都難免須要折衷(在抽象和速度之間取捨，在空間和時間之間平衡...)。雖然原則提供了方針，但在採用原則以前，必須全盤考慮全部的因素。

優勢:

減小了對象之間的依賴，研究顯示這會減小軟件的維護成本。

缺點:

採用這個原則也會致使更多的"包裝"類被製造出來，以處理和其餘組件的溝通，這可能會致使複雜度和開發時間的增長，並下降運行時的性能。

最少知識原則例子:

//錯誤的:
public House{
	WeatherStation station;

	//其餘的方法和構造器
	public float getTemp(){
		return station.getThermometer().getTemperature();
	}
}

//正確的:
public House{
	WeatherStation station;

	//其餘的方法和構造器
	public float getTemp(){
		Thermometer thermometer = station.getThermometer();
		return getTempHelper(thermometer);
	}

	public float getTempHelper(Thermometer thermometer){
		return thermometer.getTemperature();
	}
}

要點:

• 當須要使用一個現有的類而其接口並不符合你的需求時，就使用適配器。
• 當須要簡化並統一一個很大的接口或者一羣複雜的接口時，使用外觀。
• 適配器改變接口以符合客戶的指望。
• 外觀將客戶從一個複雜的子系統中解耦。
• 實現一個適配器可能須要一番功夫，也可能不費功夫，視目標接口的大小與複雜度而定。
• 實現一個外觀，須要將子系統組合進外觀中，而後將工做委託給子系統執行。
• 適配器模式有兩種形式：對象適配器和類適配器。類適配器須要用到多重繼承(在JAVA語言中不可用)
• 你能夠爲一個子系統實現一個以上的外觀
• 適配器將一個對象包裝起來以改變其接口；裝飾者將一個對象包裝起來以增長新的行爲和責任；而外觀將一羣對象"包裝"起來以簡化其接口。