一情景
今天來聊聊我對觀察者模式的理解。完全是個人理解，本篇文章也只是簡單的說一下。
在商場裡面有普通員工a和b和c，還有經理d，a和b是普通售貨員，c是保安人員，每次經理d外出，a和b就經常偷懶，但是經理回來他們需要第一時間知道這個資訊，於是他們跟c搞好關係，只要d一回來就打**通知a和b。a和b就立馬好好工作，我們把a叫做觀察者，c叫做通知者
首先是a**實現：a有姓名和經理的狀態兩個屬性，經理的狀態要麼是回來，要麼就是出去，還有乙個行為就是工作，a類如下：
public class a
c也有姓名和經理的狀態，當然還有通知a的行為，經理回來就立刻通知告訴a：
public class c
public void notice()
}但是發現乙個問題，如果這麼寫的話，只能通知a乙個人，不能通知員工b了，或許還要通知另外的員工e該幫經理泡茶。如果要通知其他人豈不是要把a類改一下?依據封閉原則這樣不好！只能想其他的辦法。
二解耦一
既然c要通知兩個，那麼就在c類裡面定義需要被通知的的同事的列表，被通知的同事叫做觀察者，通知別人的保安叫做通知者，還要有乙個往列表新增這些觀察者的方法，如果這個觀察者跟c鬧毛了，c就不在通知他了，就要有把他移除的方法。這樣解決通知觀察者的問題，但是還有乙個問題，既然是觀察者列表肯定是既能放a也能放b也能放e或者觀察者，依據依賴倒轉原則，我們可以讓這些被通知者都依賴於抽象。
c類如下：
public class c
}public void notice()
}該上班的a如下
public class a extends observe
public void work()
b就省略了，寫一下員工e的**
public class e extends observe
public void work()
這樣做是不是讓abe都依賴與抽象observe了，這樣就就解決通知很多觀察者的問題，但是這裡面c是乙個具體的類，但是具體的實現可能是c可能是d，為什麼？
三解耦二
這裡大家有沒有發現雖然觀察者abe實現了都被通知的情況，通知他的人都是保安c，但是假設有一天員工b跟保安c鬧了矛盾，那麼c就把e從列表移除了，經理回來了c就不會通知e，如果e上班睡覺就被經理抓住了，這個時候e被抓住了換一種說話就是e是被經理d通知的，經理d也成了通知者，這個時候有了兩個通知者c和d，我們又只能把這兩個共同的部分抽象出來讓具體的通知者去實現抽象類，這個時候定義乙個抽象的父類subject，讓具體的c或d去
subject
public abstract class subject
}//減少
public void remove(observe o)
public void notice()}}
具體的通知者c
public class c extends subject
public void work()
客戶端**：
c c=new c();//建立乙個具體的通知者
a a=new a("小王",c);//建立具體的觀察者
c.add(a);//通知b
e e=new e("小李",c);
c.add(e);//通知b
c.state="經理回來了！！！";//保安c得到經理回來的狀態
c.notice();//進行通知
b和e就略了，如果通知者變成經理d，我們只需要建立乙個經理d實現通知類subject。
這裡用到的observe就是對觀察者抽象的類
**的結構圖如下：
觀察者模式完美的體現了依賴置換原則的最佳體現，觀察者讓所有的工作其實就是解耦，讓耦合的雙方都依賴與抽象。
設計模式之觀察者模式
首先說了乙個自己的小例子吧，前兩天我的乙個朋友來找我玩，因為路途比較遠，我需要知道他的位置，然後安排好時間去接他，那麼在這個例子中，我就是乙個觀察者，需要時時刻刻觀察他的位置，我的朋友就是乙個被觀察者。那麼需要知道我朋友的位置，就有兩種方式，第一，我自己打 問，第二，我的朋友告訴我，下面我們來看看這...
設計模式之觀察者模式
一 作用 讓多個觀察者監視某一物件的變化，如果物件變化，則通知所有觀察者。二 例子 抽象主題類 public abstract class subject 移除觀察者 public void detach observer observer 向觀察者 們 發出通知 public void notif...
設計模式之觀察者模式
觀察者模式的定義是 定義物件間的一種一對多的依賴關係。當乙個物件的狀態發生變化時，所有依賴它的物件都會得到通知並自動更新 報社跟讀者的例子 我們用報社和讀者之間的關係來模擬觀察者模式。包含以下主體 報社 news office 讀者介面 reader 具體讀者 reader 二逼青年 reader ...