OC協(xié)議在解耦中的應用

女神

1，oc中利用協(xié)議代理解耦，

? ? delegate是OC中常用傳值模式，這是一種很好的設計模式。但是日常開發(fā)中僅限于傳值，不能充分發(fā)揮它的價值。其本質是將接口與實現(xiàn)分離，下面是一種利用協(xié)議實現(xiàn)模塊解耦的思路。

2，重構過程

? ? ? ? 1> 目標：① 項目移除任意業(yè)務模塊，編譯器不能報錯，甚至運行期不報錯。

? ? ? ? ? ? ? ? ? ? ? ? ?② 不允許硬編碼，不允許硬編碼，不允許硬編碼，，，

? ? ? ? 2> 思路。

? ? ? ? ? ? 利用協(xié)議聲明接口，在需要調用接口的地方只引入?yún)f(xié)議，然后通過中間層獲取該協(xié)議實現(xiàn)實例對象，調用接口。

? ? ? ? 3> 實現(xiàn)。

? ? ? ? ? ? 結構上，我們劃分為 中間層，功能提供者，功能調用者。下面是實現(xiàn)：

#pragma mark - ?聲明協(xié)議

我們以加載網(wǎng)絡圖片為例，先聲明協(xié)議接口。如下圖

加載webImage的協(xié)議

協(xié)議這個要歸結到公用層，看個人吧，我思考了很久，最后把它抽出來放在公用層，這是個值得思考的問題。

#pragma mark -??中間層

中間層的作用：記錄協(xié)議以及對應遵守協(xié)議的實現(xiàn)類，當調用者要獲取該協(xié)議對應實現(xiàn)實例對象時，通過記錄的類名生成實例對象返回給調用者。

中間層只有一個表屬性

中間層的結構十分簡單，只有一個字典屬性，是用來記錄Protocol 與對應實現(xiàn)類名。上圖。

中間層注冊協(xié)議的接口

中間層對于實現(xiàn)協(xié)議類的注冊接口，傳入一個協(xié)議，一個類名，中間層會將兩個參數(shù)保存到字典中。上圖。

中間層獲取delegte對象接口

對于獲取delegate對象，調用者要傳入一個協(xié)議。中間層根據(jù)記錄的協(xié)議對應的類名，初始化一個對象返回給調用者，這個對象一定是遵守傳入?yún)f(xié)議的。上圖。

至此中間層的任務完成，不依賴任何功能模塊。

#pragma mark -? ?功能提供者

功能提供者：引入要實現(xiàn)的協(xié)議，遵守協(xié)議并實現(xiàn)協(xié)議中的方法。在load中將自己實現(xiàn)的協(xié)議注冊到中間層。

實現(xiàn)協(xié)議類的load方法

#pragma mark -???功能調用者

功能調用者：根據(jù)要調用的功能，引入對應的協(xié)議，通過中間層獲取實現(xiàn)該協(xié)議的實例對象，并調用協(xié)議中的接口。

調用協(xié)議中的接口

至此我們就可以隨意更換webImage模塊，甚至直接刪掉這個模塊也不會報錯。

完結撒花。

小結：

????????這個思路是充分利用接口聲明與實現(xiàn)分開的思想。前提是認為接口不包含實現(xiàn)代碼，沒有入侵性。用引入?yún)f(xié)議的方法代替引入實現(xiàn)類。從而是項目可以自由拆卸實現(xiàn)模塊，達到解耦的目的。 利用這個思路也可以完成去model化，減少跨模塊的model帶來的耦合。