為了避免上面的問題發生,工廠模式建議讓computer類組合乙個output型別的物件,將computer類與printer類完全分離。computer物件實際組合的是printer物件還是betterprinter物件,對computer而言完全透明。當printer物件切換到betterprinter時,系統完全不受影響。**如下:
public
class computer
// 定義乙個模擬獲取字串輸入的方法
public
void
keyin(string msg)
// 定義乙個模擬列印的方法
public
void
print()
}
public
class outputfactory
public
static
void
main(string args)
}
下面是betterprinter實現類的**,betterprinter只是對原有的printer進行簡單修改,以模擬系統重構後的改進。
public
class
betterprinter
implements
output
}public
void
getdata(string msg) else
}}
某個方法需要完成某乙個行為,但這個行為的具體實現無法確定,必須等到執行該方法時才可以確定。具體一點:假設有個方法需要遍歷某個陣列的陣列元素,但無法確定在遍歷時如何處理這些元素,需要在呼叫該方法時指定具體的處理行為。
這個要求看起來有點奇怪:這個方法不僅需要普通資料可以變化,甚至還有方法執行提也需要變化,難道需要把「處理行為」作為引數傳入該方法?
對於這樣乙個需求,可以考慮使用乙個command介面來定義乙個方法,用這個方法來封裝「處理行為」。下面是command介面的**:
public
inte***ce command
上面的process方法沒有方法體,因為還無法確定這個處理行為。
下面是需要處理陣列的處理類,在這個處理類中包含乙個process方法,這個方法無法確定處理陣列的處理行為,所以使用了乙個command引數,這個引數負責對陣列的處理行為。
public
class processarray
}
通過乙個command介面,就實現了讓processarray和具體處理行為的分離,程式使用command介面代表類對陣列的處理行為。command介面也沒有提供真正的處理,只有等待需要呼叫processarray物件的process方法是,才真正傳入乙個command物件,才確定對陣列的處理行為。
下面程式實現了對陣列的兩種處理方式:
public
class
commandtest ;
// 第一次處理陣列,具體處理行為取決於printcommand
pa.process(target, new printcommand());
system.out.println("------------------");
// 第二次處理陣列,具體處理行為取決於addcommand
pa.process(target, new addcommand());
}}public
class
printcommand
implements
command
}}public
class
addcommand
implements
command
system.out.println("陣列元素的總和是:" + sum);
}}
面向介面程式設計模式
首先我申明這個詞沒有官方論證,只是我個人的乙個命名。到現在是不是有點納悶,有物件導向程式設計,面向介面程式設計,面向方面程式設計,怎麼又忽然多了乙個面向介面程式設計,不用著急聽我慢慢道來。叫 做開發模式好像不確定,實際上主要的目的就是更快更準的了解使用者需求,讓需求更改機率盡量降低,提高開發效率。我...
設計模式 物件導向五 基於介面而非實現程式設計
基於介面而非實現程式設計,是一條設計原則,它先於很多程式語言誕生,是一條比較抽象 泛化的設計思想。這條原則中的介面,可以理解為程式語言中的介面或者抽象類。基於介面而非實現程式設計的優勢 可以提高 質量,因為應用這條原則,可以將介面和實現相分離,封裝不穩定的實現,暴漏穩定的介面。上游系統面向介面而非實...
面向介面程式設計 工廠模式 單例模式
當與資料庫打交道,考慮到有各種各樣的資料庫,我們通常設計乙個dao介面與n個dao類,dao類實現dao介面,在處理類中定義乙個dao介面,並在配置檔案中設定這個介面使用的是哪個dao類。此種方法也叫控制反轉。當有好多介面時如userdao,categorydao,productdao時,我們通常設...