才疏學淺, 但也想和大家分享一下，比較抽象，如果有不懂請自行bing.com

使用【單例】代替【靜態(tài)類】 和【靜態(tài)變量】

靜態(tài)類, 靜態(tài)變量創(chuàng)建方便, 但是管理起來就麻煩了, 而且單例可以比靜態(tài)函數(shù)高明的是, 可以對共用變量進行判斷和初始化, 讓變量更加靈活, 可以進行更靈活的適配。可以使用宏來封裝單例，這樣寫起來簡化了很多。

使用【枚舉】代替【布爾值】和【數(shù)字】

當你需要通過判斷來實現(xiàn)條件時，有時創(chuàng)建布爾值是相對方便的，但是擴展就麻煩了些。我的觀點是通過縝密的構思，確定是否使用布爾值，像一些enable， selectable， visible這類只有兩種狀態(tài)的用布爾值，而包含意義更多的變量像isVideoMp4，這樣就最好設置為枚舉，因為這只能判斷mp4或者不是mp4， 而枚舉就可以擴展它的判斷
枚舉還有個功能可以在switch上被提示是否已書寫過（objc）

使用【開關】代替【布爾組】

使用方式和上面提到的類似，不一樣的是，像單片機開發(fā)一樣，對32位單個數(shù)值的每一位當做一個開關，這樣可以做到濃縮管理， 缺點是只支持0~31 共32個開關，不過擴展也好弄，某些平臺支持把它擴展得更多個開關（c#貌似專門提供一個對應開關的類）

使用【宏判斷】代替【靜態(tài)常量】判斷

開發(fā)應用和游戲的時候，會有大量的測試條件和管理調(diào)試內(nèi)容，用到【單例】【靜態(tài)常量】來判斷測試的執(zhí)行與否尚可，但是宏判斷可以讓語句在不滿足的情況下并不參與編譯，相當于注釋掉了沒用的代碼，非常方便，使用【宏開關】混合【宏判斷】和【開關】來實現(xiàn)快速的測試、上線切換，非常之實用。

使用【子線程】代替【主線程】

某些處理例如jpg壓縮，視頻編譯，處理gif等需要短時大量cpu、gpu操作時，在主線程影響到了用戶的體驗，那么就需要把處理移到子線程，而在合適的時候回到主線程更新。靈活的學習子線程調(diào)用和主線程協(xié)作還是挺有趣的。

使用【習慣命名】代替【隨心所欲命名】

自己的代碼從類名，變量名到函數(shù)名和資源文件名，都保持一致的風格，這樣在搜索查找的時候得心應手。

【時用時創(chuàng)】、【復用對象】代替【隨意創(chuàng)建】

創(chuàng)建對象對于我們來說再簡單不過了。不過當我們需求變得需要高效的時候，就需要利用好每個字節(jié)的資源。像objc的UITableView就是個很好的例子，只會需要顯示個數(shù)的cell，無論數(shù)據(jù)有多少。
另一些則是當你創(chuàng)建很多對象的時候，內(nèi)部的某些變量可能不需要隨時出現(xiàn)，那么在需要的時候去創(chuàng)建，以減少耗時和運算。

【相似歸宗】代替【對象個性】

創(chuàng)建的對象多了起來后，發(fā)現(xiàn)都有相似的功能，比如都為場景scene的功能，那么他們可以歸類統(tǒng)一來管理起來，創(chuàng)建一個父類，讓這些類都繼承于它。這樣既約束了子類，也能將類傳遞時使用父類來描述這個類的基本功能

【代理】、【通知】代替【類變量】

• delegate使用接口來弱化傳遞信息對象的耦合
• 通知則可以完全剝離開對象與對象之間的關系，但因為機制原因，效率不如delegate和變量
• 變量直接指名了類型，不夠靈活

盡量避免更多的使用第三方類庫

第三方庫很多時候會給我們帶來方便，省掉很多底層的思考，但是不要一味的追求第三方庫多就是好的觀點：

• 第三方庫對于系統(tǒng)更新并不能快速適配，某些第三方庫甚至幾年沒有維護
• 第三方庫增多也會增大軟件和游戲的體積
• 它的功能并不和我的需求吻合，有的地方是我想要的，有些地方并不需要，這時候你就要去粗取精了。
• 更新迭代快的第三方庫對于你來說也是個麻煩，比如cocos2d、cocos2dx，很多時候某個版本的框架都是由大神級老外幫忙指出問題的解決辦法
• 選擇更為成熟，更為活躍的第三方庫，反饋問題也會被大家快速解答
• 選擇開源的第三方庫，這樣查詢問題時也能知道具體原因和解決方法

希望大家會喜歡【通知】、【枚舉】、【單例】、【開關】、【宏】，有時候可能會很難用，甚至是晦澀，但是相信在大型項目上會讓你的項目更加靈活。我們的項目目的性和功能性從來都不是在一開始就注定好的，應付這些撓頭的改變，需要你將code的根基砸結實。