遠端訊息

和其他語言一樣，Objective-C語言最初設的設計也是針對在同一地址空間中執行的單一程序而設計的。

然而，在面向物件的模型中，通訊是執行時在相對自我包含的單元之間通過訊息的方式來進行的。這種方式看起來很適合程序間的通訊。因此，不同地址空間中的物件互發訊息或者是執行同一任務的不同執行緒之間互發訊息都是不難想象的。

例如，在典型的伺服器-客戶端互動時，客戶端可以向伺服器端的指定物件傳送請求，而伺服器端可以向指定的客戶端傳送通知或者其他所需的資訊；或者是在互動式應用程式中，執行一條使用者命令時，可能需要大量的計算。程式可以簡單地顯示一個對話方塊，告訴使用者程式忙中，請等待；也可以將運算工作交給次一級的任務來完成，而主要程式可以繼續接受使用者的輸入。兩個任務中的物件可以通過Objective-C中的訊息機制來進行通訊。

分散式的物件

遠端訊息機制要求Objective-C的執行時能夠在不同地址空間的物件之間建立連結、識別傳送給遠端地址空間中傳送的訊息，並把資料傳送到不同的地址空間中。同時，還要執行時能夠協調兩個任務中獨立的機制；執行時必須一直保有訊息，直到遠端接收方能夠響應該訊息為止。

Cocoa中就包含有對執行時的這種重要的擴充套件機制，那就是分散式物件架構。使用分散式物件，我們就可以向別的任務中的物件傳送訊息，或者是在同一任務的不同執行緒中執行訊息對應的方法（當在同一任務的不同執行緒間傳送遠端訊息的時候，系統對這些執行緒的處理和不同任務中的執行緒是一樣的）。注意：Cocoa中的分散式物件系統是構建在執行時系統之上的，並沒有改變Cocoa中物件的基本行為。

在傳送遠端訊息之前，應用程式必須首先和遠端接收者之間建立連結。建立連結相當於是程式中為遠端的物件在自己的地址空間中建立的代理（Proxy）。然後，程式就可以通過代理和遠端的物件進行通訊了。代理此時就代表了遠端物件，代理自身是沒有自己的標識的。應用程式可以把代理就看成是遠端的物件；在大多數情況下，代理就是遠端物件。

圖13-1就展示了遠端訊息。其中物件A和物件B通過代理進行通訊，傳送給物件B的訊息被放置在佇列中，直到物件B可以處理他們為止：

訊息的傳送者和接收者是在不同的任務中的，其排程也是相互獨立的。因此在傳送者傳送訊息的時候並不能確保接收者正好就處於空閒可以接收訊息的狀態。因此，到達接收者的訊息會被放置到佇列中，在接收者方便的時候會對其進行處理。

其中的代理並不能代替遠端物件來處理訊息，也不需要訪問其對應的類。他並不是遠端接收者的一個副本，他只是遠端物件的一個輕型的替代品。從某種意義上來講，代理是透明的；他只是接收發送者的訊息，將之傳遞給訊息的接收者並負責他們之間的通訊。他的主要功能是為別的地址空間中的物件提供一個本地的地址。然而，代理並不是完全透明的。例如，通過代理並不能直接設定或者讀取物件的例項變數。

遠端的接收者通常都是匿名的。他的型別是駐留在遠端程式中的。傳送訊息的程式不需要知道接收者的程式是怎麼設計的以及其中使用到了哪些類。傳送程式也不必使用與接收方相同的類，只需要知道遠端接收方可以響應什麼訊息即可。

基於上述的因素，接收遠端訊息的物件必須通過正式的協議來將自己的介面廣而告之。傳送方和接收方都要宣告該協議 —— 他們都引入相同的協議宣告。由於遠端物件必須遵守該協議，因此接收程式必須宣告他。傳送方則是通過宣告協議來告訴編譯器他所傳送的訊息。這是因為他可能使用了conformsToProtocol:方法和@protocol()指令來對遠端接收者進行檢測。傳送方不必實現協議中的任何方法。他之所以需要宣告該協議只是因為是他發起訊息給遠端的接收者。

在文件“基礎框架參考”和《分散式物件程式設計話題》中都談到了分散式物件架構，其中包括類NSProxy和NSConnection。