文章目錄
Adapter
問題:如何解決不相容的接口問題,或者如何爲具有不同接口的類似構件提供穩定的接口
建議:通過中介適配器對象,將構件的原有接口轉換爲其他接口
類型名稱中包含了模式名稱Adapter.這是相對常見的風格,這使得其他人在閱讀代碼或圖形時能夠很容易理解其中使用了哪些模式.
Factory
如果是某個領域對象來創建這些適配器,那麼領域對象的職責會超出了單純的應用邏輯(例如銷售總額的計算),並且會涉及與外部軟件構件連接相關的其他內容.
工廠對象如下一些優勢:
- 分離複雜創建的職責,並將其分配給內聚的幫助者對象
- 隱藏潛在的複雜創建邏輯
- 允許引入提高性能的內存管理策略,例如對象緩存或再生
注意:在ServicesFactory中,決定使用哪個類來創建的邏輯是,從外部源讀取類的名稱(例如,如果使用Java則以系統特性文件作爲外部源),然後動態加載這個類.此例中,局部地使用了數據驅動設計.這種設計對於實現適配器類的變化方面做到了防止變異原則.無需更改工廠類中的源代碼,通過修改屬性值並且確保新類存在於Java的類路徑中,我們就可以爲新的適配器類創建實例.
Singleton
ServicesFactory的設計又引發了另一個新問題:由誰來創建工廠自身,如何訪問工廠?
首先,注意在該過程中只需要一個工廠實例…有一種解決方案是,將ServicesFactory作爲參數傳遞給任何需要其可見性的地方…另一種替代方案是單實例模式
單實例的實現還存在另一個問題:爲什麼不將所有服務方法都定義成類自己的靜態方法,而是使用具有實例方法的實例對象?
- 實例方法允許定義單實例類的子類,以對其進行精化;靜態方法不是多態的而且在大多數語言中不允許在子類中對其重寫
- 大多數面向對象的遠程通信機制只支持實例方法的遠程使用,而不支持靜態方法
- 類並非在所有場景中都是單實例的.
面對上面的理由二,工廠會成爲遠程方法麼?
上面的理由三也說不過去,如果工廠的目的是爲了得到實例,並且我們沒有兩個實例從同一個工廠產生的約束,二者沒有差別,畢竟可以鞋廠以下形式:
class Factory{
public static Factory getInstance(){
//....some code
}
public Adapter getAdapter(){
//....some code
}
public static Adapter getAdapterStatic(){
return getInstance().getAdapter();
}
}
可以看出上面第三個方法完全可以通過前兩個方法來實現,減少了調用者的次數並且實現結果一樣.
Strategy
策略對象將依附於語境對象—策略對象對其應用算法.在本例中,語境對象是Sale.當getTotal消息被髮送給Sale時,它會把部分工作委派給它的策略對象.其中並不要求發給語境對象和策略對象的消息具有相同的名稱,但是這種做法十分常見.無論如何,語境對象會將其自身的引用傳遞給策略對象,這種做法十分普遍…
策略是基於多態的,並且對於變化的算法提供了防止變異.策略通常由工廠創建.
Composite
定義組合和原子對象的類,使他們實現相同的接口
Facade
Observer/Publish-Subscribe
Template Method
該模式的思想是,在超類中定義一種方法(模板方法),超類定義了算法的框架,其中既有固定部分也有變化部分.Template方法調用其他一些方法,這些方法可能會被子類覆寫.
這裏需要使用protected,在類圖中,它是表示爲#
Do It Myself
State
問題:對象的行爲依賴於它的狀態,而它的方法中包含能夠反映依賴狀態的條件動作的case邏輯.是否存在替代條件邏輯的方法
方案:給每個狀態創建狀態類,並實現一個公共接口.將語境對象中依賴於狀態的操作委派給其當前的狀態對象.
Command
爲每一個任務創建一個類,並實現共同的接口
一般爲XXXCommand,然後有一個execute方法