什麼是觀察者模式? 定義了 一種一對多的關系,讓多個觀察對象(公司員工)同時監聽一個主題對象(秘書),主題對象狀态發生變化時,會通知所有的觀察者,使它們能夠更新自己。 解決什麼問題? 将一個系統分割成一個一些類互相協作的類有一個不好的副作用,那就是需要維護相關對象間的一緻性。我們不希望為了維持一緻性而使各類緊密耦合,這樣會給維護、擴充和重用都帶來不便。觀察者就是解決這類的耦合關系的。
各個角色 抽象主題(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 ( "一排一号" );
其他設計模式:
設計模式--備忘錄模式(Memento)
設計模式--擴充卡模式(Adapter)
設計模式--代理模式(Proxy)
設計模式--裝飾模式(Decorator)
設計模式--迪米特法則(Lod/LKP)
設計模式--依賴倒轉原則
設計模式--開放/封閉原則(OCP)
設計模式--單一職責原則(SRP)