androidgilde

『壹』 Android模塊化設計方案之使用代理模式解耦

Android模塊化設計方案系列文章：

1、 Android模塊化設計方案模型圖

2、 Android模塊化設計方案之介面API化

3、 Android模塊化設計方案之使用代理模式解耦

本篇是Android模塊化設計方案的第三篇，也是對 第一篇 中ThridLibs Proxy模塊進行說明。

很多人覺得對那些優秀的第三方依賴庫再次封裝是一件多餘的事情，因為這些庫可能出自大神/大廠，或有非常高的star並且使用起來十分穩定，可以在項目中直接拿來使用。當然每個開發者都有自己的態度，我也只是根據以往的經驗，表達一下自己的看法。

作為從了解四大組件就不愁找不到工作的互聯網大時代中一路走來的Android老鳥，經歷了網路請求框架從HttpConnection到Volley再到OkHttp，也經歷了圖片載入框架從UniversalImageLoader到Picasso再到Gilde，技術的迭代隨時都會發生。讓項目架構具有良好的擴展性是在設計之初就需要考慮的東西。

那麼接下來我用一個簡單的demo來演示一下如何使用代理模式對第三方框架進行解耦。

現在我們有一個名為 thirdlib 的模塊，為我們提供圖片載入功能。

第一步：我們創建了一個新的模塊 thridlibproxy ，並且該模塊依賴於 thirdlib ，我們在該模塊中創建包私有的介面ImageLoaderInterface，這個介面中把thirdlib模塊中提供的功能抽象為介面：

第二步：創建包私有的介面的實現類ImageLoaderOneImpl，類中圖片載入的業務邏輯是通過調用 thirdlib 中的ImageLoader類實現的：

第三步：我們提供一個供外部調用的ImageLoaderOneImpl介面代理類ImageLoaderProxy：

最後我們就可以通過ImageLoaderProxy中提供的loadImage方法進行圖片的載入了。

看到這里有些盆友就會問了，在第二步的時候，我們就完成了 thirdlib 的封裝工作，為什麼還要有第三步？還有我寫一個單例類直接對 thirdlib 進行封裝不就行了，為什麼還要抽象出介面？

原因很簡單，為的就是盡可能的滿足軟體設計七大原則中的第一個： 開閉原則 。

一個好的軟體設計，需要對拓展開放，對修改關閉。我們在設計之初就要想到，在更換圖片載入框架之後如何最大程度上滿足開閉原則。

如果直接對 thirdlib 進行封裝，是面向類的開發而不是面向介面。如果此時更換圖片載入類庫，那必然會對封裝出來的類進行大量的修改，把原來的實現替換為新的實現。

使用代理模式的好處就是，我新創建一個被代理的類ImageLoaderTwoImpl：

然後只需要對第三步中的被代理類進行替換就行了。

在想要達到相同效果的時候，最大程度的滿足了開閉原則。

我們業務層模塊也和第三方庫實現了完全的解耦，我不需要知道 thridlibproxy 是如何幫我完成圖片載入工作的，但是只要調用它提供的方法就完事兒的，這也符合軟體設計七大原則中的： 最少知道原則 。
關於為何以及怎麼通過代理調用第三方依賴庫，到這里就介紹完畢了，趕快動手試試吧~

我只想說： 原則是死的，人是活的😹

如果覺得有收獲的話，歡迎點贊評論以及關注~