保留“自我”的不良做法？

Question

我有一個簡單的查詢，我想要被某人清理......保留自己是不是很糟糕？

我有一個服務器請求對象，我想做。 我希望能夠以下列方式使用它：

ARequest *request = [ARequest request: someParam];
request.delegate = self;
[request begin];

為了讓對象在自動釋放池耗盡后不會自毀，我想我需要在它的init方法中調用retain，然后在收到，處理並傳遞給它的委托時響應服務器響應。

然而，有些事情正在用這種方法引起我的警鍾。 更好的方法嗎？

Answer 1

保留self是沒有錯的，只要你按照正常的內存管理協議在一個定義明確的點釋放它。 如果一個對象要求自己存在直到某個條件滿足，那么它應該對此負責，就像它對繼續存在所需的任何其他對象一樣。

引入其他無關的管理器對象或者出於迷信的原因強加對象所有者的責任將是真正的反模式。

（垃圾收集代碼中的等效方法是，對象在結果掛起時將自己從垃圾收集中排除，或者如果您不喜歡該想法，則通過某種集合將其置為根。）

Answer 2

這不是聞所未聞的，但有點不常見。 我看到它使用的主要方式（並自己使用它）是當你處理某種半同步對象時（通過半同步我的意思是它不會阻塞主線程，但它也不會在后台線程上執行; NSURLConnection適合這個賬單）。 例如，我編寫了一個NSWindowController的子類，專門用於將窗口顯示為工作表並調用某些特定的委托回調。 基本上，你要alloc / init一個新的表單控制器並調用beginSheetForWindow: . 這將半張同步運行工作表，然后在工作表被解除時調用適當的回調。

由於調用對象不一定“擁有”工作表（將其視為iOS上的模式視圖控制器的Mac版本），工作表控制器會在顯示工作表之前立即[self retain] ，並立即[self release]清理並調用回調后。 這背后的目的是確保控制器對象在工作表完成之前保持不變。 （表格，IIRC，由runloop保留，但我還需要控制器留在附近）

就像我說的那樣，遇到你想要[self retain]的情況是非常罕見的，但這並非不可能。 但是，作為一般的經驗法則，如果你認為你需要[self retain] ，你可能想再想一想。

Answer 3

最簡單的方法是為您的請求創建一個iVar，在啟動時保留請求，並在調用最后一個委托方法時釋放它。

ARequest是您創建的課程嗎？ 它是否創建了一個新的線程來異步提交請求？

Answer 4

我曾經和你做過同樣的事情。 我在NSString上編寫了一個Category-Method，將它發送到服務器，然后打印出來。 在類別方法中我不得不調用[self retain] ，以便回調方法可以是NSString-Categroy-Method to。
我覺得很糟糕，我重新編寫了所有內容以使用Singleton，可以通過Category-Method訪問。 因此，Singleton將在必要時保留字符串。