設(shè)計模式思想換位中的另類觀察者
觀察者模式(Observers) 定義了對象之間的一對多依賴，這個一來，當一個對象改變狀態(tài)時，它所有的依賴者都會收到通知并自動更新,主題和觀察者定義了一對多的關(guān)系 觀察者依賴于主題，只要主題狀態(tài)一有改變，觀察者就會接受到通知 根據(jù)通知的風格。
當兩個對象之間松耦合，它們依然可以交互，但不太清除彼此的細節(jié)。觀察者模式提供了一種對象設(shè)計，讓主題和觀察者之間松耦合。主題只知道觀察者實現(xiàn)了某個接口(也就是Observer接口)主題不需要知道觀察者的具體類是誰，做了些什么或其他的任何細節(jié)。任何時候我們可以添加新的觀察者。因為主題唯一依賴的東西是一個實現(xiàn)Observer接口的對象列表。
松耦合的設(shè)計之所以能讓我們建立有彈性的OO系統(tǒng)，能夠應(yīng)對變化，是因為對象之間的互相依賴降到了***。所以我們?yōu)榱私换ο笾g的松耦合設(shè)計而在努力。
筆者學習過很多觀察者模式的文章，也在項目中使用過，下面我們通過一個Dome慢慢的認識體會設(shè)計模式的思想。
Demo - 氣象監(jiān)測應(yīng)用系統(tǒng)
氣象觀測局專利申請在WeatherData對象中，由WeatherData負責追蹤天氣狀態(tài)。成功以后在氣象監(jiān)測局顯示以供廣大網(wǎng)民查詢并提供接口給大型網(wǎng)站顯示，這時候訪問關(guān)系是，
注意箭頭的方向，訪問取得數(shù)據(jù)的壓力都壓在氣象局中，久而久之根據(jù)訪問量的遞增氣象局不定的添加服務(wù)器，負載均衡，緩沖等技術(shù)解決。
而知，有時候，如果您發(fā)現(xiàn)項目中后期維護的問題太多，那就回到起點從新思考問題。每次網(wǎng)民通過各大合作方網(wǎng)站訪問數(shù)據(jù)，各大合作方又來訪問氣象局得到數(shù)據(jù)。這無形中讓壓力增加。那么我們?nèi)绾螌毫Ψ植迹瑴p少無謂的浪費。
這時候讓我們回到觀察者模式中的思想，那就是“你們不要來訪問我，如果我的數(shù)據(jù)發(fā)生改變我會通知你們”。講到這里請看新的設(shè)計關(guān)系圖：
看看此時的關(guān)系設(shè)計圖表中，合作方不再從氣象局獲取到數(shù)據(jù)，而使用本地數(shù)據(jù)儲存方式，當氣象局數(shù)據(jù)發(fā)生變化更新各合作方，則將各個合作方的數(shù)據(jù)更新到***，而氣象局的數(shù)據(jù)是主題，而合作方便是也就是觀察者，兩方便是一對多的關(guān)系，氣象局不需要知道合作方取了數(shù)據(jù)如何使用，只要在獲得到新的數(shù)據(jù)后更新即可。
接近尾聲的時候，這次就不貼代碼了，講到這里實現(xiàn)起來該DOME肯定沒問題，這次雖然短短的些字，但確實本人不才些經(jīng)驗和悟性，其實我這整篇文章想表達的是，設(shè)計模式表達的一種思想，是從項目業(yè)務(wù)邏輯中和后期變化中去思考。
【編輯推薦】
