比傳遞NSDictionaries作爲參數更好的模式？

由於我們的代碼庫的成熟，我開始不喜歡傳球的字典，以此來打包的消息傳遞，或者信息更糟糕的是，函數參數的模式。它需要發送和接收函數都有一個未公開的字符串文字API。比傳遞NSDictionaries作爲參數更好的模式？

..in some function.. 
NSDictionary *info = [NSDictionary dictionaryWithObjectsAndKeys: 
         thisObject, @"thisKey", 
         thatObject, @"thatKey", 
         nil]; 

[[NSNotificationCenter defaultCenter] postNotificationName:@"MY_NOTIFICATION" object:nil userInfo:info]; 
....

，然後在someClass的聽衆

- (void)someClassListener:(NSNotification *)notification { 
    NSDictionary *info = [notification userInfo]; 

    ThisObject *ob1 = [info objectForKey:@"thisKey"]; 
    ThatObject *ob2 = [info objectForKey:@"thatKey"]; 
}

你要記住，thisKey和thatKey是該通知ThisObject類型和ThatObject的按鍵，相信你可以的地方創造一些常量，這些鍵，但這並不能真正解決問題。

而且可以說你有一個需要15個參數的函數，你不打算做一個函數與15個參數，它會更容易（雖然少可讀性）只是傳遞一個字典，但現在你有與上面相同的問題。

我在那些類的頭文件（即一個頭文件中有兩個接口）中創建了殘缺的'Message Classes'，而Message Class只是你定義併發送給創建更強壯的方法的對象列表合同，但這感覺錯了。

這將會是巨大的，如果我可以做類似typeDef在頭參數對象，但不支持NSObject的唯一的東西，像int或float等

基本上我想在消息發送者和消息接收者之間創建一個更強大的合同，即該功能或通知。

來源

2013-02-21 Shizam

你可以定義按鍵的常數。例如，請參閱UIKeyboardDidShowNotification的文檔。有一個可用於獲取有關通知的信息的所有密鑰的鏈接。

一個更好的方法將你的數據封裝成一個類，而不是一本字典。用屬性創建一個簡單的類。這將比字典更加自我記錄。您可以在.h文件中查看屬性名稱和屬性類型。

如果你發現你有需要15個參數的方法，你需要退後一步，封裝這些參數到合適的班級。也許這種方法適當地減少了幾個參數和一個類或類似的東西。

來源

2013-02-21 20:06:33 rmaddy

我提到鍵的常量並不是一個好的解決方案，因爲你仍然需要去查找關鍵是什麼，而不是爲值（對象）的內容創建一個強有力的契約，更像是一個建議。將數據封裝到一個類中是我正在研究的一個方向，但爲我想要傳遞的每條消息創建一個類似乎很麻煩，無論是2個參數都是10，您不同意嗎？ – Shizam 2013-02-21 20:17:39

@Shizam，如果這些消息將被放入不同的字典中，那麼你可能需要不止一個類。但是，如果你談論的是有時從字典中傳遞兩個鍵的消息，有時候是10個，那麼這仍然只是一個類對象。 – rdelmar 2013-02-21 20:30:17

@rdelmar在我們的程序中，我們可能會有10-15個獨特的通知，每個通知都需要自己的類來定義它的消息屬性。 – Shizam 2013-02-21 21:42:44

你想要的是一個參數對象，一個小物體，它封裝了一堆與一些其他類的便捷通信領域。在內部，參數對象可能包含一個字典，或者只包含一組指定的字段。

給參數對象一個簡單的API，讓兩個類都可以設置並獲取您使用的特定字段 - setThisKey：和getThisKey。實質上，這就是在方法和類之間記錄API。

接下來，尋找將功能移入參數對象的機會。舉例來說，如果你有這樣的事情：

param.fieldSize=[self.data size]; 
param.fieldColor=[self.data color]; 
param.flavor=[self.data lookUpTheRecipe]

您可以用

[param withField: self.data];

隨着工作封裝這一切，你可以經常做參數對象做很多有益的工作;這可以打破長期的方法，並幫助大班級擺脫多餘的責任。

來源

2013-02-21 20:07:24

我提到這是我正在看的解決方案，我看到的問題是必須爲每條消息創建一個參數對象，看起來很麻煩。另外，似乎將該對象放置在擁有該消息的類的頭部，這樣在一個頭部中就有兩個接口，這似乎讓人不悅。 – Shizam 2013-02-21 20:19:43

您可以經常在多個相關方法中共享一個參數對象。 – 2013-02-21 21:18:00

我看到沒有人反對將接口添加到類的頭文件中。但是你的參數對象的目標是向該對象添加許多有用的行爲，而不僅僅是包裝一些數據。所以，最終，參數對象可能在世界上擁有自己的位置。像NSURL這樣的類以這種方式開始。 – 2013-02-21 21:20:47

起初，有15個參數不好，在這種情況下，你應該考慮不要做這樣的回調或試圖減少數量。

如何使用通知發件人？例如，您的對象Task已完成併發送通知。接收方使用發件人訪問sender.result,sender.error,sender.anything。

如果你想這些對象之間的強聯繫（發送器/接收器），也許你應該使用的通信，而不是NSNotifications的一些其他的方式。

一些替代方案：

委託（或一些其他類型的直接方法調用的）
塊
目標+行動

它們都可以作爲一對多通過將它們存儲在一個數組中，並且它們不使用NSDictionaries進行值傳遞。

來源

2013-02-21 22:23:12 Tricertops

我們也使用代表和塊，我只是使用NSNotifications作爲示例，其中很容易看到問題。我仍然有這個塊的問題等，但我開始認爲創建參數對象來包含參數幾乎是唯一的方法來做到這一點。 – Shizam 2013-02-21 23:10:40

比傳遞NSDictionaries作爲參數更好的模式？

回答

相關問題