前言
以小說的筆法寫的設計模式系列文章，你絕對看得懂！[首發於公眾號:"聊聊程式碼"]
設計模式系列·王小二需求歷險記(一)
設計模式系列·王小二需求歷險記(二)
設計模式系列·封裝、繼承、多型
設計模式系列·初探設計模式之王小二的疑問
設計模式系列·Facade模式之MVC的煩惱
設計模式系列·Adapter 模式之如何優雅的使用別人的輪子
設計模式系列·類爆炸之Bridge模式
設計模式系列·工廠方法模式之 Code Review
設計模式系列·抽象工廠模式
------華麗的分割線------
訊息中心的重構
話說這幾天，王小二經過C哥的精心指導，初步領悟了設計模式的魅力。
於是小二又著手對訊息中心進行了設計與重構，看，下面就是小二畫的UML類圖。
小二自忖：嗯...看著還不錯嘛，不管是傳送簡訊還是傳送郵件，因為兩者都繼承自抽象類Message，所以可以方便的利用物件導向的多型性，這樣就進一步實現了針對介面程式設計，perfect!
（btw:不瞭解多型的童鞋，請戳：OOP三大特性:封裝、繼承、多型 補補課^_^）
訊息中心的新成員
新的一天又開始了，小二感覺每天都在進步，這種感覺特別充實，或許，碼農的快樂就是這麼真實簡單。
北京的地鐵依舊人潮湧動，硬著頭皮終於擠上了地鐵。9:20，小二到了公司。
“小二，你手頭還有活沒？”老大走過來說道。
“之前的需求剛剛完事，沒什麼事情了。”
“好，訊息中心現在支援傳送簡訊與郵件是吧？”
“是的，支援的。”
“嗯，不錯。你知道我們們公司微信會員特別多，所以傳送微信這塊，也要接到訊息中心來。你覺得可以實現嗎？”
“嗯...可以實現，現在訊息中心的結構很清晰，2天就能搞定！”
“好，不錯，你開始做這塊吧!”
"好的，沒問題。"
小二心想：“微信接入訊息中心還不簡單嘛，我已經對訊息中心重構了，接入一個新成員還不是分分鐘搞定的事兒！”
善用github
碼農界流行一句話：“不要重複造輪子”。
小二對這句話深有體會，最近還參與了github上幾個開源專案呢！
開工之前，小二靈機一動："傳送微信，肯定是個通用的功能，github上應該有開源的專案吧？我去找找！"
不搜不知道，一搜嚇一跳，還真不少呢。
小二在github上千挑萬選，終於選定了一個專案。
為了更清晰的將這個專案接入訊息中心，小二又針對這個專案畫了一個簡單的類圖。
畫完類圖，小二仔細分析了一下：咦？github上這個WechatMessage類中的方法，與現有訊息中心的介面不一樣啊。既然不一樣，那麼就無法繼承自抽象類Message。那麼，就無法實現多型了，也就不能針對介面程式設計了。哎，好不容易找了一個開源專案，最後空歡喜一場。難道真的要自己重寫一個WechatMessage類嗎？￣へ￣
這時，小二又想到了萬能的C哥。
小二想：“C哥或許有辦法，再去請教下C哥吧！”
Adapter模式解千愁
小二找到C哥，大體描述了下自己的問題。
“小二啊，面對新需求，你首先能想到去github上找有沒有開源的實現，這種方法是值得鼓勵的，贊一個！”
“哈哈，謝謝C哥，開源就需要有人蔘與有人用嘛！”
“嗯嗯。你這個問題，可以用設計模式中的Adapter模式去解決。”
“還有Adapter模式？望C哥指點一二。”
“我給你畫個類圖你就明白了。”
"哦哦，我明白了，中間加一個介面卡，就適配了不相容的類"。
“對的，就是這個意思。”
“你有沒有看過安卓蘋果轉接頭，那就是一個介面卡。”
“嗯嗯，見過，C哥說的太形象了，確實是！”
Adapter模式與Facade模式的區別
“C哥，前幾天你給我講的Facade模式，是對介面進行了包裝。Adapter模式，也是對介面進行了包裝適配。這兩個看似區別不大啊？”
“區別還是有的，要不然也不會有兩個設計模式的名字。”
“嗯嗯，他倆有什麼區別呢？”
“Facade模式的目的，是為了提供一個簡單易用的介面給使用者。而Adapter模式的目的，是為了適配某個類，從而保持物件的多型行為。”
“哦，這樣啊！”
“是的，最大的不同，就是他們倆的目的不同。Adapter模式最常用的場景就是用來保持物件的多型行為。”
“嗯嗯，我明白了，多謝C哥”。
“類圖都給你畫出來了，程式碼就不要我給你寫了吧？”
“哈哈，不用不用，我自己來寫就行了，有了類圖，分分鐘搞定！”
“哈哈，小二加油，有什麼不會的再問我。”
優雅的使用別人的輪子
拿著C哥畫好的類圖，小二很快進行了適配，優雅的使用了github上的專案。
3個小時過後，小二成功實現了訊息中心接入傳送微信訊息的功能。
小二心想：“這介面卡模式真管用，大大解放了我們一線碼農的生產力，以後可以優雅的使用別人的輪子了，✌️”！
轉載宣告：本文轉載自「聊聊程式碼」，搜尋「talkpoem」即可關注。
關注「聊聊程式碼」，讓我們一起聊聊“左手程式碼右手詩”的事兒。