【HeadFirst 設計模式學習筆記】1.政策模式

1.書中舉了一個鴨子類的設計，有些會飛或者會叫，有些不會飛可能也不會叫，用繼承則導緻不該有的功能通過繼承而繼承了下來，使用接口則代碼無法做到最大程度的重用。進而引出設計原則1：找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起，把會變化的部分取出并封裝起來，好讓其他部分不會受到影響 。——每個設計模式背後的精神所在。

2.我們希望運作時動态的改變一些行為，這就引出了第二個原則：針對接口程式設計，而不是針對實作程式設計。 是以，鴨子的行為将被放在分開的類——我們可以将其叫做“行為類”中，此類專門提供某行為接口的實作。針對接口程式設計的意思是針對超類型程式設計——變量的聲明類型應該是超類，通常是一個抽象類或者一個接口，如此，隻要是具體實作此超類型的類所産生的對象，都可以指定給這個變量，這也意味着，聲明類時不用理會以後執行時的真正對象類型。

針對實作程式設計

針對接口程式設計

更好的針對接口程式設計

Dog d=new Dog();

d.dark();

Animal animal=new Dog();

animal.makesound();

a = getAnimal();

a.makeSound();

不得不針對具體實作coding

利用animal多态處理

運作時才指定具體實作的對象

最後設計的樣子是兩個接口，一個飛，一個叫，每個接口中有相應的方法，然後設計不同的類對這個接口進行不同的實作。

然後在超類的設計中，行為變量被聲明為“接口”類型的變量，然後具體動作的方法由接口類型的變量相對應的方法所實作。子類中，構造函數中指明這些接口類型的變量具體對應的是哪一個具體實作。這樣的話，通過一個“接口”類型的變量，靈活性就更高了，雖然此時在構造函數中我們還是引入了具體實作。

3.進一步，我們希望可以自己設定具體的行為而不是在構造函數中寫死，那麼我們可以使用setter method，通過向外提供接口來設定從超類那繼承的接口類型的成員變量。

4.最後我們看到的設計局面是：各種鴨子繼承了Duck，飛行行為實作了FlyBehavior接口，呱呱叫行為實作了QuackBehavior接口。設計的基本理念在于行為不是繼承而來的，而是通過适當的行為對象“組合”而來。這個總結就可以歸納出第三個設計原則：多用組合，少用繼承。這樣可使系統更具有彈性。

最後我們來看看這個模式的定義：

政策模式定義了算法簇，分别封裝起來，讓它們之間可以互相替換，此模式讓方法的變化獨立于使用方法的Client，适用于繼承後的動作發生變化，要動态的改變對象的行為時。

核心思想：将is-a 轉換為has-a.

基本的思路：将一些原先要繼承的方法，以接口的方式抽象出來，然後再以實作該接口的方式定義一些類以完成實際能力的實作；同時在基類中以組合的方式将該接口的執行個體放入基類，基類同時提供設定這個執行個體的接口以及這個方法的封裝，子類繼承基類是對這些接口執行個體進行設定即可。

5.TIPs：

1）在開發中使用模式詞彙，但是不要寫一個helloworld都要扯上模式。

2）沒有所謂設計模式庫，隻有設計模式條目。

3）模式并不隻是利用了OO的設計原則。應用場景中若是沒有合适的模式則使用最基本的OO原則。

附：鴨子的設計