現(xiàn)代Objective-C七宗罪
拜移動大潮所賜，這兩年Objective-C可謂是風頭正茂，連續(xù)兩年獲得年度編程寶座，然而任何一門編程語言也不是十全十美的，這不，這個備受蘋果公司關注的Objective-C也不招人待見，原文作者Ash發(fā)表一篇博客例舉了Objective-C七宗罪。
以下是譯文：
如果你正在編寫Objective-C代碼，那么這篇文章可能會得罪你；倘若還沒，那么你無需擔心，本文我們一起來細數(shù)下Objective-C的七宗罪。
一宗罪：.xib文件太大
我之所以說Objective-C不好，有幾個原因，***的問題是當系統(tǒng)加載系統(tǒng).xib時，需要加載整個.xib；并且在啟動應用程序或者用戶交互響應環(huán)節(jié)時占據(jù)大量時間，這一點很讓人頭疼。
第二個問題是，無法重復使用視圖（或者與它相關聯(lián)的代碼），你總不會希望一直重復粘貼與復制吧。
二宗罪：無法使點語法保持一致
談及Objective-C的語法，很多開發(fā)者***感覺就變成望而卻步了。
許多開發(fā)者總認為使用點語法編寫是主觀現(xiàn)象，也許他們的想法是正確的。但是我個人認為點語法是一個較為現(xiàn)代化的方式來訪問屬性，這不屬于客觀現(xiàn)象。相反，如果你選擇使用點語法，并且一直堅持這么做。那么，建議你要么全部使用，要么干脆不要，記住，千萬不要混合及匹配使用 。
三宗罪：.m Files中的類繁多
在一個相同的文件里會出現(xiàn)很多類，這是一個很主觀的現(xiàn)象，因為這往往會利用一個有用的方式來定義，就如同小包裝模型類或者值轉(zhuǎn)換。
如果外部文件需要使用你的新類，把它放在自己的文件夾中即可。如果你#import一個視圖控制器僅僅是為了在.m file里面得到一個輔助類，那么要把重構擺在首位。
四宗罪：無法進行編譯器優(yōu)化測試
當你開發(fā)時通常會使用Xcode默認選項——關閉優(yōu)化，但最終發(fā)布前肯定還是會開啟它的，這時經(jīng)常會出嚴重的問題。
你無需調(diào)優(yōu)編譯器來做完整的回歸測試，只需一個簡單的smoke測試就足夠了。如果你有beta測試人員，那么可以進行設置，重要的是某人在測試之外能夠生成二進制文件以確保用戶能夠被控制。
五宗罪：體系結構的基本類型
Objective-C這門語言以及其運行時既是為iOS，也是為OS X而開發(fā)的。但iOS 32位而OS X是64位的。當你使用Objective-C定義原始值的時，使用int將會出現(xiàn)丟失；如同為OS X編譯時出現(xiàn)的那些半位，使用long int又顯得太蠢了。
六宗罪：不必要的-C APIs
什么是Keychain API？新的OS X APIs需要使用Sandboxing，但需要使用C嗎？這里我討論的不是核心基礎類，而是一些嚴重混亂的C。
C語言比Objective-C快不了多少。如果你想做任何實時系統(tǒng)方面或者處理音頻或視頻，可選擇使用C。在大多數(shù)情況下Objective-C是不錯的選擇。
七宗罪：無法使用自動化測試
你是否使用Objective-C進行單元測試？也許你不曾使用過。那么你曾給UI進行自動化驗證測試嗎？答案也是NO。那你曾設置過任何持續(xù)集成嗎？
我不理解Objective-C社區(qū)為什么要回避這個問題？要知道這是一個嚴重的、 系統(tǒng)性的問題。最近我才開始單元測試，我和我的同事在探索UI自動化驗收測試。沒人知道它是這么的難，也許是因為沒人做過，以致沒有這方面的資源。因此，我們必須靠自己。文檔是編寫代碼的重要組成部分，我花了整整一天的時間才弄清楚模擬對象是什么，更遑論如何使用它們。
這對于Objective-C社區(qū)來說是個嚴重的問題。此外，單元測試也值得重視且應該將其做好。
英文出自：Ashfurrow
【編輯推薦】
