最近比較煩，比較煩，比較煩，產品經理總把我為難。。。

最近在做一個線上培訓的項目，費了九牛二虎之力開發完了，這時產品經理笑嘻嘻的跑過來告訴我，那啥，改個需求，線上培訓的學員支持移除，移除了要把獲取到的相應學分扣除掉。我冷冷的看了她一眼，心想要不是看你是個女同志并且長得還行，天王老子來了也沒得商量。找到負責學分的同事A，加了一個扣除學分的接口，我這邊移除學員后調用他的接口，忙活半天，算是搞定了。

第二天，產品經理又笑嘻嘻的跑過來說，那啥，昨天跟你說的那個需求，不僅要扣除學分，還要標記缺勤。我尼瑪，你昨天咋不一起說，這不昨天沒想起來嘛，嘿嘿。沒辦法，又找到考勤的同事B，加了一個標記缺勤的接口，我這邊移除學員后調用他的接口，忙活半天，也算OK了。

第三天，產品經理又笑嘻嘻的跑過來說，那啥，昨天那個還得。。。

生氣歸生氣，需求總還是要實現的，這點基本的職業素養還是有的。

其實想一想，這算是一個比較典型的業務場景，當一個對象的改變需要同時改變其它對象，且它不知道具體有多少對象有待改變的時候，觀察者模式，是一個比較好的選擇。

觀察者模式，定義對象間一種一對多的依賴關系，使得每當一個對象改變狀態，則所有依賴于它的對象都會得到通知并自動更新，也叫做發布訂閱模式Publish/Subscribe，屬于行為型設計模式的一種。

上述的業務場景，移除學員是一個行為的發起者，同事A和B是行為的觀察者，當然可以根據你的業務場景增加同事C、D、E等等。當有移除學員的動作發生的時候，A進行相應的扣除學分操作，B進行相應的標記缺勤操作，C進行。。。

下面我們用代碼來實現產品經理小姐姐的變態需求。

1、定義行為觸發類

首先定義行為觸發的類，這個類中有一個行為移除學員的方法，當我們移除學員的時候調用這個方法。

然后可以定義它的實現類，重寫成員變更的方法，這個方法的實現邏輯無非就是通知跟它有關的對象：我要移除學員了。

那誰能收到通知呢?

2、新增觀察者

這里的觀察者就是上述場景中的同事A與同事B，他們都想要收到學員變更的通知。這里的實現很簡單，你要接收通知，把你的信息注冊過來，我這邊存儲一下，需要通知的時候，我把所有注冊者的信息拿出來，一一的進行通知;如果你不想接收通知了，注銷一下注冊信息，我把你的信息從存儲中刪掉，這樣再通知的時候，就不會通知你了。

回到代碼中，我們用一個list進行存儲所有注冊者的信息，list集合中是一個接口，要求所有觀察者都必須實現這個接口才能注冊進來，接口中會有指定的方法，所有觀察者也必須實現這個方法，這個方法就是各個觀察者在收到通知時要進行的操作，對應上述場景中，A同事更新學分，B同事標記缺勤等。這個接口可以自己定義，java也提供了Observer工具類供大家使用。代碼如下：

3、觀察者定義

這里觀察者的定義就比較簡單了，實現Observer接口，重寫update方法，在類初始化的時候把自己的信息注冊進去成為觀察者，就OK了。

4、測試

可以看到我們調用學員變更方法后，同事A和同事B都收到了通知，并執行了相應的操作。