設計模式學習心得，設計模式

設計模式學習心得，設計模式

學習到現在的主要問題是沒有進行例子的完美歷練，說白了，就是沒動手親自的試試，寫寫對應的代碼，理解一下主要的設計思想，這個應該是學習設計模式我最重要的地方，那麼現在針對之前學習的設計模式做一個總結和回顧吧

0.設計模式分析規律
在講解這個設計模式之前，我們應該學習到設計的原則，1.分析程序中變化的位置，針對變化的位置進行封裝隔離
分析是對鴨子的叫聲和會飛進行了特殊的隔離，因為這兩種行為是特殊於其他普通鴨子的行為，這裡考慮的就是封裝這個變化
第一種角度：我們考慮之前的行為都是采用繼承的關系，但是這樣所有的子類都具有叫聲和飛行的行為了，不能這樣用
第二種角度：我們采用接口的形式，讓父類實現這兩個接口，其他子類進行覆蓋，有的鴨子就覆蓋，沒有就不覆蓋，這樣的寫法帶來的問題是，以後要是有新的行為加入進來，子類和父類還要修改
引入第二個設計原則：針對接口編程，而不是實現編程
那麼這樣考慮以後，有了另一種角度
第三種角度：設計兩個接口，一個叫，一個飛行，然後寫各自的實現類，叫聲類，和飛行類，將這兩個類的接口行為組合在鴨子的父類中，即鴨子父類持有這兩個行為接口，
父類寫兩個方法，使得有些鴨子可以請求叫方法，有的可以請求飛行的方法，讓子類來傳遞飛行和叫的方式，比如:有的“呱呱叫” 有的不叫，有的飛行有的像火箭一樣
為了實時修改這兩個類，加入設置的set方法動態修改叫和飛行的行為

問題：這裡父類也有了叫和飛行的行為，是不是違背了之前說的不用繼承，特殊行為應該在某些子類上
問題：這裡要考慮我們之前說的變化是什麼？1，叫和飛行的行為區別於一般鴨子，只是這樣的一種，2.叫和飛行的行為有一類這樣的行為了

1.策略設計模式
上面的例子貌似是特意為策略設計模式制定的，那麼我們該怎麼樣分析這個模式
算法簇的替換，而不影響其他的行為

模式結構：一個接口，多個實現類，用這個接口來維護一種或多種行為，不同的實現類相互替換（非典型的策略模式）

//飛行接口
public interface FlyBehavor{
void fly();
}
//飛行行為類
public RebotFly implements FlyBehavor{

public void fly(){
//添加自身的非行為
}
}

public class Duck{

private FlyBehavor mFlyBehavor;

public Duck(FlyBehavor mFlyBehavor){
this.mFlyBehavor = mFlyBehavor;
}

public void performFly(){
mFlyBehavor.fly();
}
}



2.觀察者模式
相關例子的引入是做一個氣象發布器，將系統發布的氣象信息顯示在多個公告欄上
多個公告欄的實時更新是核心部分，變化的位置是在哪裡?比如添加或減少一個信息公告欄，信息公告欄的主要功能變化，公告欄的外觀的變化，發布信息的數據結構變化（接入其他系統的氣象信息）
之前的設計方式是否合理，這個是根據OO設計經驗來完成的，要多積累才行
之前的設計是在氣象更新器中寫死氣象信息更新的類，有信息更新，就發送給公告欄，這樣的設計有什麼問題嗎？
問題1.如果多個公告欄中有一個不用了，這樣我們要手動刪除代碼，測試，
問題2.氣象加入了新的公告信息，加入新的字段，比如溫度，濕度，風向，級別
問題3.OO設計思想是什麼？為什麼要這樣用？

問題1.違反了OO設計原則：對擴展開發，對修改關閉
問題2.將所有的類統一成一個整體
問題3.設計類交互的松耦合而努力

模式結構：
"推"消息
被觀察者（氣象站） 觀察者（公共欄）
擁有對所有觀察者的引用（集合） 提供一完整的更新接口（update）
信息更新（遍歷，將氣象信息傳遞給公共欄）
-----------------------------------------------------------------------------------
"拉"消息
被觀察者（氣象站） 觀察者（公共欄）
擁有對所有觀察者的引用（集合） 提供一完整的更新接口（update（obseverable,obj）
信息更新（遍歷，將氣象信息傳遞給公共欄）