摘要：開發模式的確立是軟件開發過程中不可缺少的一部分，就目前來說，面向過程和面向對象是兩種主要的設計方法，雖然面向對象OOP是比較流行的字眼，但不表示面向過程就一定好無作為，畢竟面向過程設計方法也有適合其應用的軟件系統：以功能操作為主，擴展性要求不高，無需過多考慮復用以及軟件的通用性能。那是不是面向過程的設計方法對于諸如系統框架擴展問題就絲毫沒有辦法了呢？
按照面向過程的基本原則，劃分系統功能模塊、模塊細分到函數、生成系統整體的結構模型，似乎在整個過程中沒有任何東西可以用來提供系統擴展，其實解決的方法還是有的，這根救命稻草就是回調機制。
一談到回調機制，當然就少不了我們的主角：系統API(通常都是)和回調函數，這兩者缺一不可。其實回調的基本思想就是由系統給我們提供一些接口，也就是常使用的API，這種函數可以將某個其他函數的地址作為其參數之一，而且可以利用該地址對這個函數進行調用，而被調用的函數就是我們通常所說的回調函數了。
下面給個回調函數使用的小例子：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
//相當于我們提到的系統API
mainFunc( void* userFunc )//當然參數不會這么簡單，只是模擬
{
while (...)
{
printf("ok!");
//調用回調函數了
if (userFunc!=NULL)
userFunc();
}
}
可以看出MainFunc可以根據函數userFunc的地址調用它。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
這樣使用者只需要定義一個函數：void myFunc()，然后按照mainFunc(&myFunc)(&只表示傳遞的是函數的地址，無具體含義)，就可以讓我們的mainFunc來調用myFunc從而實現相應的功能，這樣當然可以完成我們預期的目的－擴展現有系統。
在windows系統中，支持這種回調機制的系統API不占少數，像實現ListControl排序的SortItem()函數，還有操作Font使用的函數EnumFontFamilies()都有提供這種回調機制，使得我們的用戶有機會添加自己期望的功能實現。當然，使用回調函數并不是一個輕松的事情，如果我們的系統中存在了大量的回調函數是很難管理的，這個就與系統中存在大量全局變量一樣，出現多個函數爭相訪問同一個變量我們就很難使用簡單的邏輯來處理，容易陷入混亂，因此，盡管回調機制可以在某種程度上達到我們的目的，但切不可亂加使用，不然后果很難預料。
當然至于詳細的回調函數實現，還需要大家潛心研究，這里我只是總結一下：
1 回調函數是由開發者按照一定的原型進行定義的函數(每個回調函數都必須遵循這個原型來設計)
例如：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
BOOL CALLBACK DialogProc(
HWND hwndDlg, // handle of dialog box
UINT uMsg, // message
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
);
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
說明：
回調函數必須有關鍵詞 CALLBACK
回調函數本身必須是全局函數或者靜態函數，不可定義為某個特定的類的成員函數
2 回調函數并不由開發者直接調用執行(只是使用系統接口API函數作為起點)
3 回調函數通常作為參數傳遞給系統API，由該API來調用
4 回調函數可能被系統API調用一次，也可能被循環調用多次(SortItem就是自調用)
最后說句題外話，其實windows系統中還有另一種機制－消息機制，也是一個比較不錯的工具，能夠為很多實際的問題提供解決方法，這個以后再總結了。