觀察者模式(新手推薦)

2021-07-24 12:46:40 字數 3549 閱讀 4306

今天給大家帶來乙個較為簡單的模式,觀察者模式。如果覺得我寫得還不錯,記得關注下,我好有勇氣給大家以淺顯的語言介紹完這幾種設計模式(覺得寫得還不錯的記得關注下,我好繼續給大家更新,平時上班很忙的)。

為什麼要使用觀察者模式?

舉個簡單的例子,在一所工科學校裡(我們都知道,工科院校女生都比較少),有乙個很有教養,漂亮,溫柔的女生大家都很喜歡,自然有很多人追。女生的一舉一動,大家都很關注。比如女生半夜發了個狀態,說「我餓了」。

。。。。。。

接下來,不得了了,眾男們(假設現在有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 完美的將觀察者和被觀察的物件分離開。舉個例子,使用者介面可以作為乙個觀察者,業務資料是被觀察者,使用者介面觀察業務資料的變化,發現資料變化後,就顯示在介面上。物件導向設計的乙個原則是 系統中的每個類將重點放在某乙個功能上,而不是其他方面。乙個物件只做一件事情,並且將他做...

觀察者模式

觀察者模式定義了一種一對多的依賴關係,讓多個觀察者物件同時監聽某乙個主題物件。這個主題物件在狀態上發生變化時,會通知所有觀察者物件,讓他們能夠自動更新自己 任何乙個模式都是離不開角色的,這裡也會有幾種角色 抽象主題角色 把所有對觀察者物件的引用儲存在乙個集合中,每個抽象主題角色都可以有任意數量的觀察...