今天給大家帶來乙個較為簡單的模式，觀察者模式。如果覺得我寫得還不錯，記得關注下，我好有勇氣給大家以淺顯的語言介紹完這幾種設計模式（覺得寫得還不錯的記得關注下，我好繼續給大家更新，平時上班很忙的）。
為什麼要使用觀察者模式？
舉個簡單的例子，在一所工科學校裡（我們都知道，工科院校女生都比較少），有乙個很有教養，漂亮，溫柔的女生大家都很喜歡，自然有很多人追。女生的一舉一動，大家都很關注。比如女生半夜發了個狀態，說「我餓了」。
。。。。。。
接下來，不得了了，眾男們（假設現在有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 完美的將觀察者和被觀察的物件分離開。舉個例子，使用者介面可以作為乙個觀察者，業務資料是被觀察者，使用者介面觀察業務資料的變化，發現資料變化後，就顯示在介面上。物件導向設計的乙個原則是 系統中的每個類將重點放在某乙個功能上，而不是其他方面。乙個物件只做一件事情，並且將他做...
觀察者模式
觀察者模式定義了一種一對多的依賴關係，讓多個觀察者物件同時監聽某乙個主題物件。這個主題物件在狀態上發生變化時，會通知所有觀察者物件，讓他們能夠自動更新自己 任何乙個模式都是離不開角色的,這裡也會有幾種角色 抽象主題角色 把所有對觀察者物件的引用儲存在乙個集合中，每個抽象主題角色都可以有任意數量的觀察...