設計模式系列·Adapter模式之如何優雅的使用別人的輪子

消息中心的重構

話說這幾天，王小二通過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個小時事後，小二成功實現了消息中心接入發送微信消息的功能。

小二心想：「這適配器模式真管用，大大解放了咱們一線碼農的生產力，之後能夠優雅的使用別人的輪子了，✌️」！

設計模式等系列文章，首發於公衆號「聊聊代碼」，關注公號，讓咱們一塊兒聊聊「左手代碼右手詩」的事兒。