設計模式第一天 策略模式

讀《Head First》設計模式,個人心得、筆記。

看了第一章後,我個人總結的一句話"設計模式的重點就是把會變化的抽取出來,並對這部分針對接口編程,不是針對實現編程,而且在設計的過程中要滿足接口隔離原則。多用組成,少用繼承,更高的靈活性和可拓展性",作爲設計模式的新手,不知道這樣總結會不會有錯,但是還是希望把自己的想法寫出來,有錯的,希望大家糾正。

首先來解釋一下上面這句話的名詞:

會變化的:什麼是會變化的,我相信大家都知道,也就是程序中可能在後期會增加、刪除或者改變等變化的那一部分。比如我們在開發android時,我們要將加載到的圖片進行緩存,現在我們使用了內存緩存,如果後期我要增加存儲卡緩存,或我要自定義緩存。這時候圖片緩存在部分功能就是會變化的,因此我們要把緩存的功能抽取出來。

針對接口編程:針對接口編程,換句話來說讓這某一個功能的不同操作或實現共同實現於某一個接口,然後使用多態讓這個功能接口對象動態的指向不同的實現。接着上面的緩存,緩存圖片這是一個功能,但是緩存在內存中、緩存在存儲卡上都是不同的實現,針對接口編程,這兩種不同的實現或者用戶自定義的實現都應該實現與相同的接口,然後利用接口中的方法實現各自的操作。針對接口編程,程序可以更加的靈活,緩存接口可以指向內存緩存或存儲卡緩存。

接口隔離原則:簡單的說就是接口應該足夠的小,只要達到相應的功能或者目的就好,不應該加上其他使用不到的部分。

這是圖片緩存的UML(參考了Android源碼設計模式解析與實戰)


下面我們用《Head First》設計模式中的例子,讓大家更加的熟悉策略模式吧。

需求是這樣的,我們要實現各式各樣的鴨子,有些鴨子會叫,但是叫聲不一樣,有些不會叫,隨着鴨子的成長,鴨子的叫聲也會發生變化,也就是不同年齡段的鴨子的叫聲是不一樣的。實現的程序必須要足夠的靈活和易於拓展。

爲了讓鴨子類對象可以動態的改變它隨年齡而改變的叫聲,叫聲是變化的,我們抽取出來。並定義成接口,這樣不同的叫聲就實現這個接口。

然後我們發現,很多同一個年齡段的鴨子的叫聲都是一樣的,這樣我們就可以將不同年齡段的叫聲,集成上面的接口實現相應的叫聲,這樣要使用這種叫聲,只需要新建這一種叫聲的一個類的對象就可以了。如果單單只是鴨子類實現上面的接口,你會發現不同的鴨子假如叫聲一樣,會重複寫相同的代碼。因此,使用組成+接口,並將經常用的接口的一些實現寫成類,這樣要用時,只要新建這一個類的對象複製給接口對象就可以了。

下面我們來實現幾種常用的鴨子的叫聲。我們假設分別是aaaaaa ,bbbbb,cccccccccc

我們還要實現一種鴨子不會叫的叫聲。

對於鴨子類我們就只討論他的叫聲。

下面我們來實現鴨子類。

這裏我們可以調用setShout(IShout shout)方法進行動態的改變叫聲。通過此來改變shout對象,這樣當調用duck的shout方法是,由於shout指向的叫聲不同,因此duck發出的叫聲也就不同。

下面我們來寫一個測試的代碼。

輸出的結果:

可以看到,不同的年年齡段,鴨子的叫聲是不一樣的。

我們來總結一下:在設計的過程中,我們把會變化的部分抽取出來,並將該部分針對接口編程,而不是針對實現,這樣可以利用接口對象動態的指定相關的實現,使得代碼的靈活度很高,而且當用戶想實現自定義的接口實現時,只要改實現實現了該接口就可以了。(如果用戶想實現自定義的鴨子的叫聲時,只要該叫聲實現了IShout接口就可以了,因爲Duck鴨子類只知道IShout接口,他只要確認一種叫聲是實現了這個接口了的就可以了,但是他不關心你是怎麼實現的。)



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章