如果你寫死類型，就是程序在玩你。
如果你多用協議對象，就是你在玩程序。
稍為正規一點的產品開發流程的第一步，應該是產品經理給出原型圖，類似于下面這樣子(圖片引用自網絡，如有侵權，請第一時間告知，我會盡快撤掉，謝謝)
然后，第二步是由設計師給出效果圖，類似于下面這樣子：(圖片引用自網絡，如有侵權，請第一時間告知，我會盡快撤掉，謝謝)
大家可以看到，這兩者中間的差異非常大，如果等效果圖出來后才開始開發，將會浪費前面的太多時間。但是，如果在原型圖出來后，就直接開始開發，一不小心，后期就會是沒完沒了的反復修改。
(圖片引用自網絡，如有侵權，請第一時間告知，我會盡快撤掉，謝謝)
VIPER，通過把APP架構劃分為線框、視圖、展示、交互、實體、數據六個層次，使得開發工作可以在最早的時候就參與進來，并且完全可以開發出后面無須改變的整體架構代碼。
使用VIPER架構，可以在AppDelegate里通過唯一的一個實例對象管理整個APP的依賴，并且非常直觀地管理整個APP的實例對象關系。
我在實際使用過程中，因為不希望依賴及實例管理類過于龐大以及提高代碼復用率，把依賴管理和實例管理的代碼分散到各個線框層的類里面。每一個縱向的業務所包含的類的依賴和實例管理，都交由各自的業務線框來完成。
通過視圖、事件、交互三組協議的協議對象，使得視圖顯示、事件處理、交互數據這三塊的類可以得到徹底分離。未來面對APP功能修改或增加時，將會變得非常容易，代碼變化被約束到了最小的范圍。
隨著對VIPER架構的日漸熟悉，我越來越感受到協議對象的好處。通過協議對象的大量使用，每個類都可以也應該做成功能相對單一，專職專責，代碼復用成本迅速降低。
通過越來越多的“單一職責”類的積累，將會極大地提高開發工作的效率和質量。
歡迎大家跟我討論VIPER架構的相關問題，我會將我所知道的所有VIPER方面的知識和經驗分享給大家：）
后記(下面有聊家常為主，沒時間沒興趣的朋友請直接忽略)：
我一直猶豫要不要寫后記，因為一直以來，我的文字都會寫很多我自己的生活經歷和思考。這一塊有相當一部分朋友并不喜歡，認為我只需要把技術分享出來就可以了，沒有人對我的生活和思考有任何興趣。
后來，我覺得相對于技術的分享，我的生活和思考，才是日后對我真正有意義的東西。但為了不影響只關心技術的朋友，所以才有上面一開始的“后記聲明”。
因為最近投簡歷上的一些經歷，促使我打算每天寫技術博客，最簡單的目的自然是為了記錄和展示自己的所學所知。更深一層的目的是希望自己能保持一個表達的習慣，把腦袋里的所有信息都清出來，這樣才方便我去思考新的信息。當然，以我的經驗，只要我堅持表達，就可以得到源源不斷的幫助和機會。
為了不讓自己在表達上有過多的壓力，我給自己定了一個非常低的指標：100字。今天當然已經超了，光技術這一塊就有600多字。希望自己可以一直寫下去。從記錄自己的開發工作和技術閱讀開始，一直寫下去。
今天兒子被非常臟的公共浴室給嚇哭了，我得快點多賺點錢給老婆兒子換更好的房子住才行。
今天跟粉絲群里的朋友聊了一下，怎樣才能更好的積累技術？目前我自己的結論還是：快速做一個簡單的框架，然后每天每事每處反復去完善它。希望在技術積累上可以不斷地提速：）
