Ruby開發者如何享受Objective-C
Ruby 和 Objective-C 這兩種語言看上去好像天南地北：一種是動態語言，另一種則是靜態語言；一種是解釋型語言，另一種是編譯型語言；一種有簡潔的語法，另一種則是有點冗長的語法。從優雅的角度來看，Ruby似乎更能給我們一種自由的編程體驗，所以很多人都放棄了Objective-C。
但這是一個不幸的笑話。Objective-C其實并不像別人認為的那樣是件緊身衣，它和Ruby一樣都受Smalltalk影響，它擁有很多 Ruby開發者都喜愛的語言功能–動態方法查找、鴨子類型、開放的類和通常情況下高度可變的runtime等這些功能在Objective-C中同樣存在，即使那些不出名的技術也是一樣。Objective-C的這些功能都要歸功于它的IDE和編譯器，但也是因為它們才使你不能自由地編寫代碼。
但是等一下，怎么能說Objective-C是動態語言呢？難道它不是建立在C語言的基礎上？
你可以在Objective-C代碼中包含任何C或C++的代碼，但這不意味著Objective-C僅限于C或C++代碼。Objective- C中所有有意思的類操作和對象內省都是來自于一個叫Objective-C Runtime的東西。這個Objective-C Runtime可以和Ruby解釋器相媲美。它包含了強大的元編程里所需要的所有重要特性。
其實C語言和Ruby一樣是支持這些特性的，用property_getAttributes或method_getImplementation方法就能將selector對應到具體實現(一個selector處理一個方法)，并判斷這個對象能否對這個selector做出反應，再遍歷子類樹。在Objective-C的眾多方法中，最重要的就是objc_msgSend方法，是它推動了應用中的每次消息發送。
消息的傳遞
Smalltalk才是實至名歸的***種面向對象語言，它用“從一個對象發送信息給另一個對象”的新概念取代了“調用函數”的舊概念，對后面的語言發展產生了深遠的影響。
你可以在Ruby中通過這樣寫來實現消息的發送：
- receiver.the_message argument
Objective-C的實現方式和Ruby的差不多：
- [receiver theMessage:argument];
這些消息實現了鴨子類型的方式，也就是說關注的不是這個對象的類型或類本身，而是這個對象能否對一個消息做出反應。
發送消息真的是非常棒的事，但是只有當消息在傳送數據時，它的價值才會被發揮地更大：
- receiver.send(:the_message, argument)
和
- [receiver performSelector:@selector(theMessage:)
- withObject:argument];
正如Ruby中方法需要symbol支持一樣，Objective-C中selector也需要string來支持。（在Objective-C中沒有symbol。）這樣就可以讓你通過動態的方式使用一個方法。你甚至可以通過NSSelectorFromString方法來使用string創建一個selector，并在一個對象里執行它。同樣的，我們可以在Ruby中也可以創建一個string或symbol，并把傳給Object#send方法。
當然，無論是哪種語言，一旦你將一個消息發送給不能處理該消息的對象，那么默認情況下就會拋出一個異常，還會導致應用的崩潰。
當你想在調用一個方法前判斷一下這個對象是否能夠執行這個方法，你可以用Ruby中的respond_to？方法來檢查：
- if receiver.respond_to? :the_message
- receiver.the_message argument
- end
Objective-C中也有差不多的方法：
- if ([receiver respondsToSelector:@selector(theMessage:)]) {
- [receiver theMessage:someThing];
- }
變得越來越動態
如果你想在一個不能修改的類（像系統類）中添加你想要的方法，那么Objective-C里的category一定不會讓你失望 — 很像Ruby中的“開放類”。
舉個例子，如果你想將Rails中的to_sentence方法添加到NSArray類中，我們只需要對NSArray這個類進行擴展就好了：
- @interface NSArray (ToSentence)
- - (NSString *)toSentence;
- @end
- @implementation NSArray (ToSentence)
- - (NSString *)toSentence {
- if (self.count == 0) return @"";
- if (self.count == 1) return [self lastObject];
- NSArray *allButLastObject = [self subarrayWithRange:NSMakeRange(0, self.count-1)];
- NSString *result = [allButLastObject componentsJoinedByString:@", "];
- BOOL showComma = self.count > 2;
- result = [result stringByAppendingFormat:@"%@ and ", showComma ? @"," : @""];
- result = [result stringByAppendingString:[self lastObject]];
- return result;
- }
- @end
Category是在編譯的時候將方法添加到程序中 — 讓我們在runtime中動態捕捉它們怎么樣？
有些消息可以嵌套數據，就像Rails的dynamic finders。Ruby通過對method_missing 和 respond_to這兩個方法的重寫，先匹配模式，再將新方法的定義添加到這個對象中。
Objective-C中的流程是差不多，但我們不是重寫doesNotRecognizeSelector:方法（相當于Ruby中的method_missing方法），而是在resolveClassMethod:方法中捕捉Category添加的方法。假設我們有一個叫+findWhere:equals:的類方法，它可以得到property的名稱和值，那么通過正則表達式就可以很容易實現找到property的名字，并通過block來注冊這個selector。
- + (BOOL)resolveClassMethod:(SEL)sel {
- NSString *selectorName = NSStringFromSelector(sel);
- NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"^findWhere(\\w+)Equals:$" options:0 error:nil];
- NSTextCheckingResult *result = [regex firstMatchInString:selectorName options:0 range:NSMakeRange(0, selectorName.length)];
- if (result) {
- NSRange propertyNameRange = [result rangeAtIndex:1];
- NSString *propertyName = [selectorName substringWithRange:propertyNameRange];
- IMP implementation = imp_implementationWithBlock((id) ^(id self, id arg1) {
- return [self findWhere:propertyName equals:arg1];
- });
- Class metaClass = object_getClass(self);
- class_addMethod(metaClass, sel, implementation, "@@:@@");
- return YES;
- }
- return [super resolveClassMethod:sel];
- }
這個方法的優點就是我們不需要去重寫respondsToSelector:，因為每個在類中注冊過的selector都會去調用這個方法。現在讓我們調用[RGSong findWhereTitleEquals:@“Mercy”]。當findWhereTitleEquals:***次被調用的時候，runtime并不知道這個方法，所以它會調用resolveClassMethod:，這時我們就將findWhereTitleEquals:這個方法動態添加進去，當第二次調用findWhereTitleEquals:的時候，因為它已經被添加過了，所以就不會再調用resolveClassMethod:了。
這里還有一些別的方法來實現捕捉動態方法。你可以通過重寫resolveClassMethod: 和 resolveInstanceMethod:方法（就像上面的一樣），可以將消息傳遞給不同的對象或全權接管這個“調用”，并在消息傳遞之前，做你想這個消息要完成的任何事。這些方法都會導致運行成本的增加，特別在-forwardInvocation:中會達到頂峰，在這種情況下我們必須要實例化一個對象才能去執行它們。-forwardInvocation:方法中默認調用doesNotRecognizeSelector方法，這導致了應用的頻繁異常或崩潰。
內省
動態方法決議并不只是像Ruby和Objective-C這樣的語言的技術支持。你也可以通過在runtime中用一種有意思的方式去操作這些對象。
就像在Ruby中調用MyClass#instance_methods一樣，你可以在Objective-C中調用class_copyMethodList([MyClass class], &numberOfMethods)來得到一個對象中方法的列表。你還可以通過class_copyPropertyList方法得到一個類中property的列表，它能在你的模型中實現不可思議的內省。比如在這個Rap Genius應用中，我們用這個功能來將JSON中的字典映射到本地對象上。
（如果你非常喜歡Ruby中的mixin，那么Objective-C強大的動態支持也能能實現同樣的效果。 Vladimir Mitrovic有一個叫Objective-Mixin的庫，它能在runtime時將一個類中的實現復制到另一個類中。）
現學現用
所有的動態工具都可以用來創建像Core Data這樣的東西，Core Data是一個有點像ActiveRecord的持久化對象圖。在Core Data中，relationship是“有缺陷的”，也就是說他們只有在被別的對象訪問時，才會被加載。每個property的accessor和 mutator在runtime中都被重寫（使用的就是我們上面提到的動態方法決議）。如果我們訪問了一個還沒有被加載的對象時，框架就會從持久性儲存中 動態加載這個對象并將它返回。它保持了內存的低利用率，避免了在任何一個物體被獲取時，實體對象圖表都要被加載到內存中這樣情況的發生。
當Core Data實體中的mutator被調用時，系統會將那個對象標記為需要清理，不需要去重寫每個property的getter和setter。
這就是元程序，羨慕吧！
什么是編譯器？
很明顯，Objective-C和Ruby并不是同一種語言，目前為止***的不同就是Objective-C是一種編譯型語言。
這就是這些技術中最需要注意的地方。在編譯時，編譯器會先確定你應用使用的每個selector是不是都在應用中。如果你處理的這個對象有類型信息，那么編譯器也會檢查確保這個selector在頭文件有聲明過，這樣做就是為了防止在對象中調用未聲明的selector。有些方法可以繞過這些討厭的限制，包括關閉相關的編譯警告。這里就是實踐元程序化的Objective-C***的練習。
你可以通過將selector的類型儲存為不知道的類型或id來從對象中刪除這些類型信息。因為編譯器不認識這個類型，所以它只能假設你的程序可以接受發給它的任何消息（假設這些消息在應用中的其他地方被聲明了，并且相關的編譯標識已經打開）。
善意的忠告：如果我們關掉編譯器標識和把對象保存成id類型，那么將會非常危險的事！其實Objective-C中***的東西之一就是編譯器（是的，比元程序還要好）。類型檢查保證了我們更快的寫和重構代碼，也是我們在編程時少犯錯誤。因為沒有人會關掉那些警告，所以你很難去分享你那些id類型的代碼。大部分Objective-C開發者還是更愿意使用更強的類型而不是元程序。
事實證明Objective-C更受束縛–但因為編譯器能提高更多的安全性和速度，所以我們只能選擇這樣并承擔后果。
事實再次告訴我們，這些語言都是差不多的，Ruby開發者應該享受Objective-C，即使那些中括號讓我們望而卻步。
原文鏈接： Soroush Khanlou 翻譯：墨日陽光
