現代Objective-C七宗罪

　　拜移動大潮所賜，這兩年Objective-C可謂是風頭正茂，連續兩年獲得年度程式設計寶座，然而任何一門程式語言也不是十全十美的，這不，這個備受蘋果公司關注的Objective-C也不招人待見，原文作者Ash發表一篇部落格例舉了Objective-C七宗罪。

　　以下是譯文：

　　如果你正在編寫Objective-C程式碼，那麼這篇文章可能會得罪你；倘若還沒，那麼你無需擔心，本文我們一起來細數下Objective-C的七宗罪。

　　一宗罪：.xib檔案太大

　　我之所以說Objective-C不好，有幾個原因，最大的問題是當系統載入系統.xib時，需要載入整個.xib；並且在啟動應用程式或者使用者互動響應環節時佔據大量時間，這一點很讓人頭疼。

　　第二個問題是，無法重複使用檢視（或者與它相關聯的程式碼），你總不會希望一直重複貼上與複製吧。

　　二宗罪：無法使點語法保持一致

　　談及Objective-C的語法，很多開發者第一感覺就變成望而卻步了。

　　許多開發者總認為使用點語法編寫是主觀現象，也許他們的想法是正確的。但是我個人認為點語法是一個較為現代化的方式來訪問屬性，這不屬於客觀現象。相反，如果你選擇使用點語法，並且一直堅持這麼做。那麼，建議你要麼全部使用，要麼乾脆不要，記住，千萬不要混合及匹配使用 。

　　三宗罪：.m Files中的類繁多

　　在一個相同的檔案裡會出現很多類，這是一個很主觀的現象，因為這往往會利用一個有用的方式來定義，就如同小包裝模型類或者值轉換。

　　如果外部檔案需要使用你的新類，把它放在自己的資料夾中即可。如果你#import一個檢視控制器僅僅是為了在.m file裡面得到一個輔助類，那麼要把重構擺在首位。

　　四宗罪：無法進行編譯器優化測試

　　當你開發時通常會使用Xcode預設選項——關閉優化，但最終釋出前肯定還是會開啟它的，這時經常會出嚴重的問題。

　　你無需調優編譯器來做完整的迴歸測試，只需一個簡單的smoke測試就足夠了。如果你有beta測試人員，那麼可以進行設定，重要的是某人在測試之外能夠生成二進位制檔案以確保使用者能夠被控制。

　　五宗罪：體系結構的基本型別

　　Objective-C這門語言以及其執行時既是為iOS，也是為OS X而開發的。但iOS 32位而OS X是64位的。當你使用Objective-C定義原始值的時，使用int將會出現丟失；如同為OS X編譯時出現的那些半位，使用long int又顯得太蠢了。

　　六宗罪：不必要的-C APIs

　　什麼是Keychain API？新的OS X APIs需要使用Sandboxing，但需要使用C嗎？這裡我討論的不是核心基礎類，而是一些嚴重混亂的C。

　　C語言比Objective-C快不了多少。如果你想做任何實時系統方面或者處理音訊或視訊，可選擇使用C。在大多數情況下Objective-C是不錯的選擇。

　　七宗罪：無法使用自動化測試

　　你是否使用Objective-C進行單元測試？也許你不曾使用過。那麼你曾給UI進行自動化驗證測試嗎？答案也是NO。那你曾設定過任何持續整合嗎？

　　我不理解Objective-C社群為什麼要回避這個問題？要知道這是一個嚴重的、 系統性的問題。最近我才開始單元測試，我和我的同事在探索UI自動化驗收測試。沒人知道它是這麼的難，也許是因為沒人做過，以致沒有這方面的資源。因此，我們必須靠自己。文件是編寫程式碼的重要組成部分，我花了整整一天的時間才弄清楚模擬物件是什麼，更遑論如何使用它們。

　　這對於Objective-C社群來說是個嚴重的問題。此外，單元測試也值得重視且應該將其做好。

　　英文出自：Ashfurrow