今天給大家帶來乙個較為簡單的模式,觀察者模式。如果覺得我寫得還不錯,記得關注下,我好有勇氣給大家以淺顯的語言介紹完這幾種設計模式(覺得寫得還不錯的記得關注下,我好繼續給大家更新,平時上班很忙的)。
為什麼要使用觀察者模式?
舉個簡單的例子,在一所工科學校裡(我們都知道,工科院校女生都比較少),有乙個很有教養,漂亮,溫柔的女生大家都很喜歡,自然有很多人追。女生的一舉一動,大家都很關注。比如女生半夜發了個狀態,說「我餓了」。
。。。。。。
接下來,不得了了,眾男們(假設現在有a,b,c三個男生同時喜歡上了改女生)著急了,都想用自己的方法讓女生填飽肚子(a:走,帶你吃kfc。b:別動,我給你買了送到你樓下。c:自己畫個餅,看看就行了)。當然以c的這種方式,肯定沒戲,咳咳,扯遠了。那麼用偽**如何表示呢?
abstract class boy
// a 照顧人的方式
class boya extends boy
}//b 照顧人的方式
class boyb extends boy
}//c 照顧人的方式
class boyc extends boy
}//下面這個是女孩類
class girl
}當然,我們尊重每個人愛人的方式。現在不是糾結這個的時候,我們看上面偽**的表示有什麼問題嗎?
就在下看,有發現幾個問題:
作為女孩,首先我要知道誰喜歡我啊,不然通知錯人了怎麼辦?(實際情況是,儘管你知道有人喜歡你,但是這個人是誰你知道嗎?)
又有人喜歡女孩了,也想照顧她。但是不想讓女孩知道,只想默默地付出。按照我們現在這種寫法,只有女孩知道誰喜歡她才會通知到,不知道的就不通知了。
其他使用觀察者模式有什麼好處
看了我們上面的寫法,發現這種寫法是不合適的。我們有沒有解決辦法呢?
答案當然是有啊。但是首先我們應明確自己的需求。
我只要主動關注女孩就行了,不用等通知,自己要主動,畢竟幸福靠自己爭取。
女孩魅力大,我們要允許其他人也喜歡(不限於a,b,c),畢竟每個人都有愛與被愛的權利。
所以,觀察者模式來救場。
(宣告下,我有空了就去學uml。這個畫的不夠標準,希望能說明問題。)
那麼對應於我們這個例子,之間關係又是怎樣的呢?
那我們為何不用**實現下呢?
observer
public inte***ce observer
boypublic abstract class boy
boya
public class boya extends boy implements observer
@override
public void update()
@override
public void caredarling()
}boyb
public class boyb extends boy implements observer
@override
public void update()
@override
public void caredarling()
}boyc
public class boyc extends boy implements observer
@override
public void update()
@override
public void caredarling()
}subject
public inte***ce subject
girl
public class girl implements subject
@override
public void addobserver(observer boy)
@override
public void removeobserver(observer boy)
@override
public void notifyobservers()
}public void hungrey()
}測試類observertest
public class observertest
}結果:
好了,到此我們觀察者模式就簡單地描述完了。回到開篇前我們的兩個問題,我們現在這種模式有沒有解決問題呢?
1. 作為女孩,首先我要知道誰喜歡我啊,不然通知錯人了怎麼辦?(實際情況是,儘管你知道有人喜歡你,但是這個人是誰你知道嗎?)
我們現在在girl(subject實現類)中維護乙個陣列或者佇列,用來儲存觀察者。並不需要知道觀察者是誰。我們在建立girl的時候將佇列初始化(換句話說,我知道肯定有人喜歡我,但是具體是誰,我並不需要知道)。
又有人喜歡女孩了,也想照顧她。但是不想讓女孩知道,只想默默地付出。按照我們現在這種寫法,只有女孩知道誰喜歡她才會通知到,不知道的就不通知了。
現在即便是有boyc,boyd出現,在建立的時候就自己偷偷關注了女孩,當女孩餓了的時候,並不需要改變原有的**就可實現通知所有的。(多好,我們的這種實現方式。畢竟暗戀也是美好的)。
然而在實際中,主題subject在通知觀察者observer的時候會攜帶一些資料,這就不得不提一下觀察者模式的兩種模式:推(push)模式和拉(pull)模式。
推模型:顧名思義,就是我不管你observer想要什麼,我給你什麼你接收什麼就是了。這種模式的使用場景就是需求較簡單,且subject和observer類協商好返回資料的型別。弊端當然也很明顯就是眾observer口難調,我不知道你想要什麼,大家返回都一樣。可以想象成任性的女孩,我給你什麼你要也得接受,不要也得接受。
全寫的話量有點大,所以只貼部分**:
public inte***ce subject
可以看出,這個地方我們將state作為引數傳出去,然後在observer中被動接收。
public inte***ce observer
拉模型:就是觀察者(observer)自己站起來了,想要什麼就給什麼。一般我們把主題類該類物件作為引數傳遞出去,然後觀察者可以利用反射等方式拿到自己想要的,推模型的問題解決了,大家(眾多觀察者)可以各取所需。可以這麼理解,付出這麼多,女孩追到手了,把自己都交給你了。
public inte***ce subject
girl
...@override
public void notifyobservers(subject subject)
}public void hungrey()
...observer
public inte***ce observer
好了,觀察者模式到此介紹完畢,大家有什麼問題可以與我討論。當然文中錯誤在所難免,懇請批評指正。
python觀察者模式 python 觀察者模式
python 觀察者模式 前言e 寫的倉促就不截uml類圖了,書本chapter10,p313能看到圖 一旦觀察的主題有更新,就會通知到觀察者們,下面的例子是最簡單的乙個觀察者範例,假設這是一群投機分子密切關注 軍 火 倉庫的產品與數量變動 class inventory def init self...
觀察者模式
觀察者模式 observer 完美的將觀察者和被觀察的物件分離開。舉個例子,使用者介面可以作為乙個觀察者,業務資料是被觀察者,使用者介面觀察業務資料的變化,發現資料變化後,就顯示在介面上。物件導向設計的乙個原則是 系統中的每個類將重點放在某乙個功能上,而不是其他方面。乙個物件只做一件事情,並且將他做...
觀察者模式
觀察者模式定義了一種一對多的依賴關係,讓多個觀察者物件同時監聽某乙個主題物件。這個主題物件在狀態上發生變化時,會通知所有觀察者物件,讓他們能夠自動更新自己 任何乙個模式都是離不開角色的,這裡也會有幾種角色 抽象主題角色 把所有對觀察者物件的引用儲存在乙個集合中,每個抽象主題角色都可以有任意數量的觀察...