科普文，給大家介紹觀察者模式的使用場合及其優(yōu)缺點。

觀察者模式是比較常用的設計模式之一，尤其是系統(tǒng)里面涉及到多個復雜子系統(tǒng)時，經(jīng)常會使用到。

它就像系統(tǒng)里面某個子模塊的跑腿，一旦該子模塊發(fā)生變化，它就要為這個子模塊通知其他的子模塊。

一個經(jīng)典的例子就是我們操作系統(tǒng)所使用到的GUI界面，當我們在GUI系統(tǒng)里面使用各種應用程序時，只需要用鼠標輕輕點擊軟件右上方的全屏/非全屏，軟件里面全部的組件就會進行相應的縮放，這里面使用到的就是觀察者模式。

觀察者模式定義:

• 定義對象之間多對一的依賴關系，保證當被依賴的對象發(fā)生變化時，所有的依賴者會被自動更新。
• 當一個對象需要通知另外一些對象，而你無法預知哪些對象將被通知時，通過觀察者模式，克制減少對象的偶合關系。

在單片機開發(fā)里面，串口通信是很重要的通信手段。在業(yè)務代碼里面，有很多子模塊都關注著串口通信的數(shù)據(jù)。假設在串口數(shù)據(jù)來臨的時候，我們需要去通知各個子模塊。

偽代碼實現(xiàn):

//串口中斷
urat_isr()
{
...
  //通過設置全局變量來通知子模塊一
  notify_module1 = 1;
  //通過設置全局變量來通知子模塊二
  notify_module2 = 1;
  //通過設置全局變量來通知子模塊三
  notify_module3 = 1;
...
}

...
//主函數(shù),創(chuàng)建多個線程來處理不同任務
int main()
{
...
//線程1(子模塊一)
create_thread1();
//線程2(子模塊二)
create_thread2();
//線程3(子模塊三)
create_thread3();
...

}

在上面的代碼實現(xiàn)中，串口數(shù)據(jù)發(fā)生更新時，通過給各個全局變量置1來通知各個子模塊。等到各個子模塊得到運行機會后，判斷并更新串口通信數(shù)據(jù)。

在這個實現(xiàn)方案中，串口數(shù)據(jù)通過全局變量來通知子模塊的方式非常死板，一旦需要通知的子模塊發(fā)生變化，必須要改動串口中斷部分代碼。

在多個子系統(tǒng)同時監(jiān)視某一個子系統(tǒng)時，應該添加一個觀察者模塊，來解開通信引起的子系統(tǒng)耦合。

偽代碼實現(xiàn):

//定義觀察對象的數(shù)量
#define num 3

//定義觀察對象
typedef struct object
{
   //定義觀察對象的通知接口
   void (*update)();
}Object;

//定義觀察者模塊
typedef struct observer
{
   Object* objectList[num];
}Observer;

//定義一個觀察者模塊
Observer aobserver;
//主函數(shù),創(chuàng)建多個線程來處理不同任務
int main()
{
//初始化各個觀察對象
aobserver.objectList[0]->update = Update_module1;
aobserver.objectList[1]->update = Update_module2;
aobserver.objectList[2]->update = UpdateUpdate_module3;
...
//線程1(子模塊一)
create_thread1();
//線程2(子模塊二)
create_thread2();
//線程3(子模塊三)
create_thread3();
...

}
//串口中斷
urat_isr()
{
...
 for(i = 0; i < num; i++)
   aobserver.objectList[i]->update();
...
}

各個子模塊的通知接口，可以像這樣子來實現(xiàn):

//module1通知接口
void Update_module1()
{
  //通過設置全局變量來通知子模塊一
  notify_module1 = 1;
}

//module2通知接口
void Update_module2()
{
  //通過設置全局變量來通知子模塊一
  notify_module2 = 1;
}

//module3通知接口
void Update_module3()
{
  //通過設置全局變量來通知子模塊一
  notify_module3 = 1;
}

這就是c語言中的觀察者模式，它可以動態(tài)地增加、減少觀察對象，解除子模塊間的直接耦合，可以很好地預防程序需求發(fā)生變化。

但是在實際使用過程中，需要考慮一下開發(fā)效率和運行效率問題:

• 一個被觀察者，多個觀察對象，開發(fā)和調試過程中會稍微復雜一些。

• 通知函數(shù)盡可能不要有太大的運行開銷，實在需要進行一些耗時的操作，可以考慮引進類似于Linux系統(tǒng)"中斷上下文"這樣子的機制。