什麼是觀察者模式?
定義了 一種一對多的關係,讓多個觀察對象(公司員工)同時監聽一個主題對象(祕書),主題對象狀態發生變化時,會通知全部的觀察者,使它們可以更新本身。
解決什麼問題?
將一個系統分割成一個一些類相互協做的類有一個很差的反作用,那就是須要維護相關對象間的一致性。咱們不但願爲了維持一致性而使各種緊密耦合,這樣會給維護、擴展和重用都帶來不便。觀察者就是解決這類的耦合關係的。
各個角色
抽象主題(Subject):它把全部觀察者對象的引用保存到一個彙集裏,每一個主題均可以有任何數量的觀察者。抽象主題提供一個接口,能夠增長和刪除觀察者對象。
具體主題(ConcreteSubject):將有關狀態存入具體觀察者對象;在具體主題內部狀態改變時,給全部登記過的觀察者發出通知。
抽象觀察者(Observer):爲全部的具體觀察者定義一個接口,在獲得主題通知時更新本身。
具體觀察者(ConcreteObserver):實現抽象觀察者角色所要求的更新接口,以便使自己的狀態與主題狀態協調。
經過實例說明:
//抽象觀察者角色
public interface Watcher
{
public void update(String str);
}<strong>
</strong>
//定義抽象的主題角色,即抽象的被觀察者
//抽象主題角色,watched:被觀察
public interface Watched
{
public void addWatcher(Watcher watcher);
public void removeWatcher(Watcher watcher);
public void notifyWatchers(String str);
}
public class ConcreteWatcher implements Watcher
{
@Override
public void update(String str)
{
System.out.println(str);
}
}<strong>
</strong>
//主題角色
import java.util.ArrayList;
import java.util.List;
public class ConcreteWatched implements Watched
{
// 存放觀察者
private List<Watcher> list = new ArrayList<Watcher>();
@Override
public void addWatcher(Watcher watcher)
{
list.add(watcher);
}
@Override
public void removeWatcher(Watcher watcher)
{
list.remove(watcher);
}
@Override
public void notifyWatchers(String str)
{
// 自動調用其實是主題進行調用的
for (Watcher watcher : list)
{
watcher.update(str);
}
}
}<strong>
</strong>
//test
public class Test
{
public static void main(String[] args)
{
Watched girl = new ConcreteWatched();
Watcher watcher1 = new ConcreteWatcher();
Watcher watcher2 = new ConcreteWatcher();
Watcher watcher3 = new ConcreteWatcher();
girl.addWatcher(watcher1);
girl.addWatcher(watcher2);
girl.addWatcher(watcher3);
girl.notifyWatchers("開心");
}
}<strong>
</strong>
實際應用場景 (內容來自:http://blog.csdn.net/swengineer/article/details/6268244)
/**
* 觀察者模式應用場景實例
*
* 免責聲明:本文只是以哈票網舉例,示例中並未涉及哈票網任何業務代碼,所有原創,若有雷同,純屬巧合。
*
* 場景描述:
* 哈票以購票爲核心業務(此模式不限於該業務),但圍繞購票會產生不一樣的其餘邏輯,如:
* 1、購票後記錄文本日誌
* 2、購票後記錄數據庫日誌
* 3、購票後發送短信
* 4、購票送抵扣卷、兌換卷、積分
* 5、其餘各種活動等
*
* 傳統解決方案:
* 在購票邏輯等類內部增長相關代碼,完成各類邏輯。
*
* 存在問題:
* 1、一旦某個業務邏輯發生改變,如購票業務中增長其餘業務邏輯,須要修改購票核心文件、甚至購票流程。
* 2、日積月累後,文件冗長,致使後續維護困難。
*
* 存在問題緣由主要是程序的"緊密耦合",使用觀察模式將目前的業務邏輯優化成"鬆耦合",達到易維護、易修改的目的,
* 同時也符合面向接口編程的思想。
*
* 觀察者模式典型實現方式:
* 1、定義2個接口:觀察者(通知)接口、被觀察者(主題)接口
* 2、定義2個類,觀察者對象實現觀察者接口、主題類實現被觀者接口
* 3、主題類註冊本身須要通知的觀察者
* 4、主題類某個業務邏輯發生時通知觀察者對象,每一個觀察者執行本身的業務邏輯。
*
* 示例:如如下代碼
*
*/
#===================定義觀察者、被觀察者接口============
/**
*
* 觀察者接口(通知接口)
*
*/
interface ITicketObserver //觀察者接口
{
function onBuyTicketOver($sender, $args); //獲得通知後調用的方法
}
/**
*
* 主題接口
*
*/
interface ITicketObservable //被觀察對象接口
{
function addObserver($observer); //提供註冊觀察者方法
}
#====================主題類實現========================
/**
*
* 主題類(購票)
*
*/
class HipiaoBuy implements ITicketObservable { //實現主題接口(被觀察者)
private $_observers = array (); //通知數組(觀察者)
public function buyTicket($ticket) //購票核心類,處理購票流程
{
// TODO 購票邏輯
//循環通知,調用其onBuyTicketOver實現不一樣業務邏輯
foreach ( $this->_observers as $obs )
$obs->onBuyTicketOver ( $this, $ticket ); //$this 可用來獲取主題類句柄,在通知中使用
}
//添加通知
public function addObserver($observer) //添加N個通知
{
$this->_observers [] = $observer;
}
}
#=========================定義多個通知====================
//短信日誌通知
class HipiaoMSM implements ITicketObserver {
public function onBuyTicketOver($sender, $ticket) {
echo (date ( 'Y-m-d H:i:s' ) . " 短信日誌記錄:購票成功:$ticket<br>");
}
}
//文本日誌通知
class HipiaoTxt implements ITicketObserver {
public function onBuyTicketOver($sender, $ticket) {
echo (date ( 'Y-m-d H:i:s' ) . " 文本日誌記錄:購票成功:$ticket<br>");
}
}
//抵扣卷贈送通知
class HipiaoDiKou implements ITicketObserver {
public function onBuyTicketOver($sender, $ticket) {
echo (date ( 'Y-m-d H:i:s' ) . " 贈送抵扣卷:購票成功:$ticket 贈送10元抵扣卷1張。<br>");
}
}
#============================用戶購票====================
$buy = new HipiaoBuy ();
$buy->addObserver ( new HipiaoMSM () ); //根據不一樣業務邏輯加入各類通知
$buy->addObserver ( new HipiaoTxt () );
$buy->addObserver ( new HipiaoDiKou () );
//購票
$buy->buyTicket ( "一排一號" );
其餘設計模式: