[Design Pattern] The Observer Pattern
??? 作者:Flyingis
??? 在討論設計模式時,我喜歡用英文名來稱呼各種模式,覺得這樣會更為準確一些。設計模式在Java開發領域已經是炙手可熱的山芋,披上了這件戰袍,似乎就可以在程序設計中立于不敗之地,不僅可以規范自己的武功招式,還能夠看清其他高手的武功套路。在接下來[Design Pattern]一系列的隨筆中,我將系統的研究各種常用的設計模式,主要的參考資料是《Head First Design Patterns》,主要的思路是,介紹基本概念(雖然做Java開發的熟手已經對此熟悉的不得了),將思維轉換為代碼設計,談談在實際中開發的應用,也許還會有各種模式的弊端。
??? Observer模式是常用的幾種設計模式之一,其主要組成部分有:一組關注事件發生的對象,當事件發生時對象應該做的具體事情,以及決定對象參與或退出關注事件行為的控制器。注意,現在不要站在軟件設計的角度上來考慮前面的這些名詞,站在生活的角度上來看待會更為恰當?!禜ead First Design Patterns》中介紹的例子通俗易懂,老板決定哪些人成為他某個項目組的員工,去參與某個項目的開發,當然他也可以將某員工從項目組中調離出來,或是開除。在這個過程中,員工就是關注事件發生的對象,某個項目的開發即員工應該做的具體事情,老板擁有控制與調度的權利。
??? Observer在程序設計中使用最為廣泛是事件響應機制。列舉《Ajax in Action》中的一段代碼:
/*
?命名空間對象?
*/
var
?jsEvent
=
new
?Array();

/*
el:DOM元素
eventType:JavaScript事件類型,如onclick、onmousemove等
*/
jsEvent.EventRouter
=
function
(el,eventType)
{
??
this
.lsnrs
=
new
?Array();
??
this
.el
=
el;
??el.eventRouter
=
this
;
??el[eventType]
=
jsEvent.EventRouter.callback;
}
/*
增加一個監聽器
*/
jsEvent.EventRouter.prototype.addListener
=
function
(lsnr)
{
??
this
.lsnrs.append(lsnr,
true
);
}
/*
去除一個監聽器
*/
jsEvent.EventRouter.prototype.removeListener
=
function
(lsnr)
{
??
this
.lsnrs.remove(lsnr);
}
/*
通知所有需要響應事件的方法,當事件產生時即調用這些方法
*/
jsEvent.EventRouter.prototype.notify
=
function
(e)
{
??
var
?lsnrs
=
this
.lsnrs;
??
for
(
var
?i
=
0
;i
<
lsnrs.length;i
++
)
{
????
var
?lsnr
=
lsnrs[i];
????lsnr.call(
this
,e);
??}
}
/*
定義事件回調函數,this指向DOM元素
*/
jsEvent.EventRouter.callback
=
function
(event)
{
??
var
?e
=
event?
||
?window.event;
??
var
?router
=
this
.eventRouter;
??router.notify(e)
}
??? 其中,關注事件發生的對象是lsnr,被保存在一系列的數組lsnrs中。事件產生時應該做的具體事情在notify方法體現??刂破鲃t是removeListener和addListener來完成,它們決定需要哪些對象來關注事件的發生(這里說的“對象”仍然是廣義的,非面向對象中的“對象”)。這樣就完成了一個簡單的JavaScript事件響應的設計,遵循的是Observer設計模式。
??? Java API內建了一些接口、類來幫助實現Observer模式,具體可以參考java.util包中的Observer接口和Observable類。
??? Observer模式在軟件設計中使用的非常廣泛,在事件響應、對象監控、動態響應等領域具有重要的實際應用價值,除此之外,它還可以有效幫助軟件設計向Loosely Coupled Design方向發展,降低模塊之間的耦合,順應軟件設計發展的潮流。但是,對于一個簡單的,對擴展性沒有太多要求的應用而言,刻意在應用中引入Observer模式,只會增加代碼量,對軟件的快速開發和效率提升沒有任何好處,還不如將代碼寫的簡單易懂更好。
??? 在討論設計模式時,我喜歡用英文名來稱呼各種模式,覺得這樣會更為準確一些。設計模式在Java開發領域已經是炙手可熱的山芋,披上了這件戰袍,似乎就可以在程序設計中立于不敗之地,不僅可以規范自己的武功招式,還能夠看清其他高手的武功套路。在接下來[Design Pattern]一系列的隨筆中,我將系統的研究各種常用的設計模式,主要的參考資料是《Head First Design Patterns》,主要的思路是,介紹基本概念(雖然做Java開發的熟手已經對此熟悉的不得了),將思維轉換為代碼設計,談談在實際中開發的應用,也許還會有各種模式的弊端。
??? Observer模式是常用的幾種設計模式之一,其主要組成部分有:一組關注事件發生的對象,當事件發生時對象應該做的具體事情,以及決定對象參與或退出關注事件行為的控制器。注意,現在不要站在軟件設計的角度上來考慮前面的這些名詞,站在生活的角度上來看待會更為恰當?!禜ead First Design Patterns》中介紹的例子通俗易懂,老板決定哪些人成為他某個項目組的員工,去參與某個項目的開發,當然他也可以將某員工從項目組中調離出來,或是開除。在這個過程中,員工就是關注事件發生的對象,某個項目的開發即員工應該做的具體事情,老板擁有控制與調度的權利。
??? Observer在程序設計中使用最為廣泛是事件響應機制。列舉《Ajax in Action》中的一段代碼:















































??? 其中,關注事件發生的對象是lsnr,被保存在一系列的數組lsnrs中。事件產生時應該做的具體事情在notify方法體現??刂破鲃t是removeListener和addListener來完成,它們決定需要哪些對象來關注事件的發生(這里說的“對象”仍然是廣義的,非面向對象中的“對象”)。這樣就完成了一個簡單的JavaScript事件響應的設計,遵循的是Observer設計模式。
??? Java API內建了一些接口、類來幫助實現Observer模式,具體可以參考java.util包中的Observer接口和Observable類。
??? Observer模式在軟件設計中使用的非常廣泛,在事件響應、對象監控、動態響應等領域具有重要的實際應用價值,除此之外,它還可以有效幫助軟件設計向Loosely Coupled Design方向發展,降低模塊之間的耦合,順應軟件設計發展的潮流。但是,對于一個簡單的,對擴展性沒有太多要求的應用而言,刻意在應用中引入Observer模式,只會增加代碼量,對軟件的快速開發和效率提升沒有任何好處,還不如將代碼寫的簡單易懂更好。
posted on 2006-09-30 16:40 Flyingis 閱讀(3026) 評論(1) 編輯 收藏 所屬分類: 架構與設計