函式介面卡

介面卡模式是一種常用的設計模式，介面卡將乙個類的介面轉換成客戶希望的另外乙個介面。介面卡模式使得原本由於介面不相容而不能一起工作的那些類可以在一起工作。

簡單來說介面卡模式就是設計乙個介面卡，例項化乙個實現具體功能的類物件作為自己的成員。然後介面卡提供一些方法，這些方法實際上都將轉化成對這個成員的方法的呼叫。在轉化過程中，還可以進行一些額外的操作。

stl裡面的容器介面卡正是用了介面卡模式這種思想，stack(棧)和queue(佇列)實際上只是個容器介面卡。它們的內部都是用強大的deque(雙端佇列)實現的，只不過遮蔽和改造了一下它的介面以適用於不用的場合。

在gof的設計模式中，對介面卡模式講了兩種型別，類介面卡和物件介面卡。其實還有一種函式介面卡，比如mfc中的cwnd::create()和cwnd::createex()。create()可以用簡單少量的引數來建立視窗，createex()雖然引數較多，但提供了更多的定製。跟蹤進去發現create()和createex()並非是完全不同的實現。create()裡面實際上也是補齊引數後呼叫createex()。這也是一種簡單的函式介面卡，mfc中類似的還有很多。當我們設計類方法、設計api時，不妨學習這種做法。先實現乙個很強大的methodex()，然後再根據具體需要提供method1(),method2()等方法，當然這些方法最終都是呼叫methodex()實現。如果你還是不太理解的話請看我下面這個例子，雖然可能不太恰當。

問題是這樣的：我已經把乙個網頁html內容獲取到了，現在我想從html中提取出那些我需要的資訊。該html頁面上是乙個學生資訊表，有學生的學號、姓名、性別、**、住址、成績等資訊。起初我想把學號和對應的成績提取出來，組成一對一對的(make_pair)，放到map容器裡，這樣便可以根據學號直接得到成績。於是我寫乙個函式，該函式傳入包含html內容的cstring物件，返回乙個map物件。

bool extractscore(const cstring &strhtml, map&map_studentscore)
if (map_temp.size() > 0)
else
return false;
}

過了一段時間，我又需要乙個功能，從html中提取出學號、姓名和成績，儲存到資料庫中。於是我先定義乙個資料結構：

struct score
;

然後寫乙個函式：

bool extractscore(const cstring &strhtml, vector&vec_studentscore)
if (vec_temp.size() > 0)
else
return false;
}

寫完以後，我就琢磨，不對呀！如果過段時間我不僅要獲取學號、姓名和成績，還要獲取性別、**、住址等資訊呢？豈不是又要寫乙個這樣的函式？如果我想只獲取姓名和**，又要寫乙個這樣的函式？而且上面這兩個函式中，在while迴圈中提取學號和成績的過程完全是相同的。應該把相同的地方提取出來。

不如這樣，我寫乙個很強大的函式，能一次把所有資訊都提取出來，再用介面卡去包裝以適應不同的場合。於是乙個強大的函式誕生了：

struct studentinfo
;bool extractinfo(const cstring &strhtml, vector&vec_studentinfo)
if (vec_temp.size() > 0)
else
return false;
}

然後再改造之前的兩個函式，都呼叫這個強大的extractinfo獲取所有資訊後，進行篩選、裝配，再返回。

第乙個：

bool extractscore(const cstring &strhtml, map&map_studentscore)
else
return false;
}

第二個：

bool extractscore(const cstring &strhtml, vector&vec_studentscore)
else
return false;
}

這樣，以後再有不用的需求，我只需要再寫乙個適配函式，呼叫我這個強大的函式後，對結果進行篩選、裝配再返回即可。比如我要將所有資訊組合成乙個長長的字串一次性返回。只需寫乙個適配函式，該適配函式呼叫強大函式後要做的事只有組合資料並返回。

也許你會覺得奇怪，這樣**量不是更多了嗎？並且效率也降低了。其實**最多的地方是在從html提取資訊的那個迴圈那裡，那裡可達300多行，只是在這裡我沒有寫出來。如果那部分重複重複的寫在不同的函式中的話，**量可想而知。關於效率問題，這樣做確實會降低效率，畢竟如果我只想提取學號和成績，實際呼叫的時候也會提取所有資訊，並且還要經過介面卡篩選裝配。但在實際應用中，這點效率差距其實是可以忽略的，就比如我這個程式，最大的效率瓶頸還是在獲取html網頁時網速問題上。優點當然也是明顯的，如果**比較複雜，需求經常變化，**經常需要增改，這無疑是一種相對較好的設計。而且效率問題也不是不可以改進。比如我們這個強大的函式是不是可以增加乙個引數，用這個引數來控制它什麼內容需要獲取，什麼內容不需要獲取。

函式介面卡

STL介面卡 函式介面卡

函式介面卡

函式介面卡

相關推薦

STL介面卡函式介面卡