如果你寫死類型，就是程序在玩你逗柴。
如果你多用協(xié)議對象，就是你在玩程序亡嫌。
稍為正規(guī)一點的產(chǎn)品開發(fā)流程的第一步嚎于，應該是產(chǎn)品經(jīng)理給出原型圖，類似于下面這樣子(圖片引用自網(wǎng)絡挟冠，如有侵權于购，請第一時間告知，我會盡快撤掉知染，謝謝)
然后肋僧，第二步是由設計師給出效果圖，類似于下面這樣子：(圖片引用自網(wǎng)絡控淡，如有侵權嫌吠，請第一時間告知，我會盡快撤掉掺炭，謝謝)
大家可以看到辫诅，這兩者中間的差異非常大，如果等效果圖出來后才開始開發(fā)涧狮，將會浪費前面的太多時間炕矮。但是，如果在原型圖出來后者冤，就直接開始開發(fā)肤视，一不小心，后期就會是沒完沒了的反復修改涉枫。
(圖片引用自網(wǎng)絡邢滑，如有侵權，請第一時間告知愿汰，我會盡快撤掉困后，謝謝)
VIPER，通過把APP架構(gòu)劃分為線框尼桶、視圖操灿、展示、交互泵督、實體趾盐、數(shù)據(jù)六個層次，使得開發(fā)工作可以在最早的時候就參與進來，并且完全可以開發(fā)出后面無須改變的整體架構(gòu)代碼救鲤。
使用VIPER架構(gòu)久窟，可以在AppDelegate里通過唯一的一個實例對象管理整個APP的依賴，并且非常直觀地管理整個APP的實例對象關系本缠。
我在實際使用過程中斥扛，因為不希望依賴及實例管理類過于龐大以及提高代碼復用率，把依賴管理和實例管理的代碼分散到各個線框?qū)拥念惱锩娴で隆Ｃ恳粋€縱向的業(yè)務所包含的類的依賴和實例管理稀颁，都交由各自的業(yè)務線框來完成。
通過視圖楣黍、事件匾灶、交互三組協(xié)議的協(xié)議對象，使得視圖顯示租漂、事件處理阶女、交互數(shù)據(jù)這三塊的類可以得到徹底分離。未來面對APP功能修改或增加時，將會變得非常容易，代碼變化被約束到了最小的范圍尤揣。
隨著對VIPER架構(gòu)的日漸熟悉，我越來越感受到協(xié)議對象的好處憔杨。通過協(xié)議對象的大量使用，每個類都可以也應該做成功能相對單一蒜胖，專職專責芍秆，代碼復用成本迅速降低。
通過越來越多的“單一職責”類的積累翠勉，將會極大地提高開發(fā)工作的效率和質(zhì)量。
歡迎大家跟我討論VIPER架構(gòu)的相關問題霉颠，我會將我所知道的所有VIPER方面的知識和經(jīng)驗分享給大家：）
后記(下面有聊家常為主对碌，沒時間沒興趣的朋友請直接忽略)：
我一直猶豫要不要寫后記，因為一直以來蒿偎，我的文字都會寫很多我自己的生活經(jīng)歷和思考朽们。這一塊有相當一部分朋友并不喜歡，認為我只需要把技術分享出來就可以了诉位，沒有人對我的生活和思考有任何興趣骑脱。
后來，我覺得相對于技術的分享苍糠，我的生活和思考叁丧，才是日后對我真正有意義的東西。但為了不影響只關心技術的朋友，所以才有上面一開始的“后記聲明”拥娄。
因為最近投簡歷上的一些經(jīng)歷蚊锹，促使我打算每天寫技術博客，最簡單的目的自然是為了記錄和展示自己的所學所知稚瘾。更深一層的目的是希望自己能保持一個表達的習慣牡昆，把腦袋里的所有信息都清出來，這樣才方便我去思考新的信息摊欠。當然丢烘，以我的經(jīng)驗，只要我堅持表達些椒，就可以得到源源不斷的幫助和機會播瞳。
為了不讓自己在表達上有過多的壓力，我給自己定了一個非常低的指標：100字摊沉。今天當然已經(jīng)超了狐史，光技術這一塊就有600多字。希望自己可以一直寫下去说墨。從記錄自己的開發(fā)工作和技術閱讀開始骏全，一直寫下去。
今天兒子被非常臟的公共浴室給嚇哭了尼斧，我得快點多賺點錢給老婆兒子換更好的房子住才行姜贡。
今天跟粉絲群里的朋友聊了一下，怎樣才能更好的積累技術棺棵？目前我自己的結(jié)論還是：快速做一個簡單的框架楼咳，然后每天每事每處反復去完善它。希望在技術積累上可以不斷地提速：）
