橋梁模式的結(jié)構(gòu)與示意性源代碼(編輯修改稿)
2025-07-14 16:29 本頁面
【文章內(nèi)容簡介】 號碼、信用卡電話、PIN標識電話等等，必修對現(xiàn)有dial中使用char[10]存儲號碼改為能夠撥打任意長度的電話號碼。顯然，所有的調(diào)制解調(diào)器客戶程序都必須更改?？蛻敉饬藢φ{(diào)制解調(diào)器客戶程序的更改，因為他們別無選擇。糟糕的是，現(xiàn)在必須要去告訴DedUser的編寫者，他們必須要更改他們的代碼！你可以想象他們聽到這個會有多高興。本來他們是不用調(diào)用dial的。這就是許多項目都會具有的那種有害的混亂依賴關系。系統(tǒng)某一部分中的一個雜湊體(kludge)創(chuàng)建了一個有害的依賴關系，最終導致系統(tǒng)中完全無關的部分出現(xiàn)問題。如果使用ADAPTER模式解決最初的問題的話，就可以避免這個嚴重問題。如圖：請注意，雜湊體仍然存在。適配器仍然要模擬連接狀態(tài)。然而，所有的依賴關系都是從適配器發(fā)起的。雜湊體和系統(tǒng)隔離，藏身于幾乎無人知曉的適配器中。BRIDGE模式看待這個問題，還有另外一個方式?，F(xiàn)在，出現(xiàn)了另外一種切分Modem層次結(jié)構(gòu)的方式。如下圖：這不是一個理想的結(jié)構(gòu)。每當增加一款新硬件時，就必須創(chuàng)建兩個新類一個針對專用的情況，一個針對撥號的情況。每當增加一種新連接類型時，就必須創(chuàng)建3個新類，分別對應3款不同的硬件。如果這兩個自由度根本就是不穩(wěn)定的，那么不用多久，就會出現(xiàn)大量的派生類。在類型層次結(jié)構(gòu)具有多個自由度的情況中，BRIDGE模式通常是有用的。我們可以把這些層次結(jié)構(gòu)分開并通過橋把它們結(jié)合到一起，而不是把它們合并起來。如圖：我們把調(diào)制解調(diào)器類層次結(jié)構(gòu)分成兩個層次結(jié)構(gòu)。一個表示連接方法，另一個表示硬件。這個結(jié)構(gòu)雖然復雜，但是很有趣。它的創(chuàng)建不會影響到調(diào)制解調(diào)器的使用者，并且還完全分離了連接策略和硬件實現(xiàn)。 ModemConnectController的每個派生類代表了一個新的連接策略。在這個策略的實現(xiàn)中可以使用sendlmp、receivelmp、 diallmp和hanglmp。新imp方法的增加不會影響到使用者?？梢允褂肐SP來給連接控制類增加新的接口。這種做法可以創(chuàng)建出一條遷移路徑，調(diào)制解調(diào)器的客戶程序可以沿著這條路徑慢慢地得到一個比dial和hangup層次更高的API。五、另外一個實際應用Bridge模式的例子該例子演示了業(yè)務對象（BusinessObject）通過Bridge模式與數(shù)據(jù)對象（DataObject）解耦。數(shù)據(jù)對象的實現(xiàn)可以在不改變客戶端代碼的情況下動態(tài)進行更換。//BridgepatternRealWorldexampleusingSystem。using//AbstractionclassBusinessObject{//FieldsprivateDataObjectdataObject。protectedstringgroup。//ConstructorspublicBusinessObject(stringgroup){=group。}//PropertiespublicDataObjectDataObject{set{dataObject=value。}get{returndataObject。}}//MethodsvirtualpublicvoidNext(){()。}virtualpublicvoidPrior(){()。}virtualpublicvoidNew(stringname){(name)。}1
法律信息相關推薦
鄂ICP備17016276號-1