如果你寫死類型，就是程序在玩你。

如果你多用協(xié)議對象，就是你在玩程序。

稍為正規(guī)一點的產(chǎn)品開發(fā)流程的第一步，應(yīng)該是產(chǎn)品經(jīng)理給出原型圖，類似于下面這樣子(圖片引用自網(wǎng)絡(luò)，如有侵權(quán)，請第一時間告知，我會盡快撤掉，謝謝)

原型圖

然后，第二步是由設(shè)計師給出效果圖，類似于下面這樣子：(圖片引用自網(wǎng)絡(luò)，如有侵權(quán)，請第一時間告知，我會盡快撤掉，謝謝)

效果圖

大家可以看到，這兩者中間的差異非常大，如果等效果圖出來后才開始開發(fā)，將會浪費前面的太多時間。但是，如果在原型圖出來后，就直接開始開發(fā)，一不小心，后期就會是沒完沒了的反復(fù)修改。

VIPER

(圖片引用自網(wǎng)絡(luò)，如有侵權(quán)，請第一時間告知，我會盡快撤掉，謝謝)

VIPER，通過把APP架構(gòu)劃分為線框、視圖、展示、交互、實體、數(shù)據(jù)六個層次，使得開發(fā)工作可以在最早的時候就參與進(jìn)來，并且完全可以開發(fā)出后面無須改變的整體架構(gòu)代碼。

使用VIPER架構(gòu)，可以在AppDelegate里通過唯一的一個實例對象管理整個APP的依賴，并且非常直觀地管理整個APP的實例對象關(guān)系。

我在實際使用過程中，因為不希望依賴及實例管理類過于龐大以及提高代碼復(fù)用率，把依賴管理和實例管理的代碼分散到各個線框?qū)拥念惱锩?。每一個縱向的業(yè)務(wù)所包含的類的依賴和實例管理，都交由各自的業(yè)務(wù)線框來完成。

通過視圖、事件、交互三組協(xié)議的協(xié)議對象，使得視圖顯示、事件處理、交互數(shù)據(jù)這三塊的類可以得到徹底分離。未來面對APP功能修改或增加時，將會變得非常容易，代碼變化被約束到了最小的范圍。

隨著對VIPER架構(gòu)的日漸熟悉，我越來越感受到協(xié)議對象的好處。通過協(xié)議對象的大量使用，每個類都可以也應(yīng)該做成功能相對單一，專職專責(zé)，代碼復(fù)用成本迅速降低。

通過越來越多的“單一職責(zé)”類的積累，將會極大地提高開發(fā)工作的效率和質(zhì)量。

歡迎大家跟我討論VIPER架構(gòu)的相關(guān)問題，我會將我所知道的所有VIPER方面的知識和經(jīng)驗分享給大家：）

后記(下面有聊家常為主，沒時間沒興趣的朋友請直接忽略)：

我一直猶豫要不要寫后記，因為一直以來，我的文字都會寫很多我自己的生活經(jīng)歷和思考。這一塊有相當(dāng)一部分朋友并不喜歡，認(rèn)為我只需要把技術(shù)分享出來就可以了，沒有人對我的生活和思考有任何興趣。

后來，我覺得相對于技術(shù)的分享，我的生活和思考，才是日后對我真正有意義的東西。但為了不影響只關(guān)心技術(shù)的朋友，所以才有上面一開始的“后記聲明”。

因為最近投簡歷上的一些經(jīng)歷，促使我打算每天寫技術(shù)博客，最簡單的目的自然是為了記錄和展示自己的所學(xué)所知。更深一層的目的是希望自己能保持一個表達(dá)的習(xí)慣，把腦袋里的所有信息都清出來，這樣才方便我去思考新的信息。當(dāng)然，以我的經(jīng)驗，只要我堅持表達(dá)，就可以得到源源不斷的幫助和機會。

為了不讓自己在表達(dá)上有過多的壓力，我給自己定了一個非常低的指標(biāo)：100字。今天當(dāng)然已經(jīng)超了，光技術(shù)這一塊就有600多字。希望自己可以一直寫下去。從記錄自己的開發(fā)工作和技術(shù)閱讀開始，一直寫下去。

今天兒子被非常臟的公共浴室給嚇哭了，我得快點多賺點錢給老婆兒子換更好的房子住才行。

今天跟粉絲群里的朋友聊了一下，怎樣才能更好的積累技術(shù)？目前我自己的結(jié)論還是：快速做一個簡單的框架，然后每天每事每處反復(fù)去完善它。希望在技術(shù)積累上可以不斷地提速：）