四、調制解調器問題
感覺《敏捷軟件開發－原則、模式與實踐》中關於Bridge模式的例子很好。（《Java與模式》一書33章的對變化的封裝一節也寫得很不錯，推薦大家讀一讀。它深入的闡述了《Design Patterns Explained》一書中"1）Design to interfaces. 2)Favor composition over inheritance. 3)Find what varIEs and encapsulate it"的三個觀點。）。
如圖所示，有大量的調制解調器客戶程序在使用Modem接口。Modem接口被幾個派生類HayesModem、USRoboticsModem和EarnIEsModem實現。它很好地遵循了OCP、LSP和DIP。當增加新種類的調制解調器時，調制解調器的客戶程序不會受影響。
假定這種情形持續了幾年，並有許多調制解調器的客戶程序都在使用著Modem接口。現出現了一種不撥號的調制解調器，被稱為專用調制解調器。它們位於一條專用連接的兩端。有幾個新應用程序使用這些專用調制解調器，它們無需撥號。我們稱這些使用者為DedUser。但是，客戶希望當前所有的調制解調器客戶程序都可以使用這些專用調制解調器。他們不希望去更改許許多多的調制解調器客戶應用程序，所以完全可以讓這些調制解調器客戶程序去撥一些假(dummy)電話號碼。
如果能選擇的話，我們會把系統的設計更改為下圖所示的那樣。
我們把撥號和通信功能分離為兩個不同的接口。原來的調制解調器實現這兩個接口，而調制解調器客戶程序使用這兩個接口。DedUser只使用Modem接口，而DedicateModem只實現Modem接口。但這樣做會要求我們更改所有的調制解調器客戶程序--這是客戶不允許的。
一個可能的解決方案是讓DedicatedModem從Modem派生並且把dial方法和hangup方法實現為空，就像下面這樣：
