我有一个简单的查询，我想被某人清除……保留自我是不好的做法吗？
我有一个我想做的服务器请求对象。我希望能够以下列方式使用它：
ARequest *request = [ARequest request: someParam];
request.delegate = self;
[request begin];
为了使对象在自动释放池耗尽后不会自毁，我想我需要在它的 init 方法中调用一个保留，然后在服务器响应被接收、处理并交付给它的委托后释放。
但是，这种方法在我脑海中敲响了警钟。更好的方法来做到这一点？
保留没有错self，只要您按照正常的内存管理协议在某个明确定义的点释放它。如果一个对象要求自己存在直到满足某个条件，它应该为此负责，就像它对它需要继续存在的任何其他对象一样。
引入其他无关的管理器对象或出于迷信的原因将责任强加给对象的所有者将是这里真正的反模式。
（垃圾收集代码中的等效方法是让对象在结果未决时将自己从垃圾收集中排除，或者如果您不喜欢这个想法，则通过某种集合将其根植。）
这不是闻所未闻，但有点不常见。我看到它使用（并自己使用）的主要方式是当你处理某种半同步对象时（半同步我的意思是它不会阻塞主线程，但它也不会阻塞主线程）在后台线程上执行；一个NSURLConnection适合这个账单）。例如，我编写了一个子类NSWindowController，专门用于将窗口显示为工作表并调用某些特定的委托回调。基本上，你alloc/init一个新的工作表控制器并调用beginSheetForWindow:. 这将半同步地运行工作表，然后在关闭工作表时调用适当的回调。
由于调用对象不一定“拥有”工作表（将其视为 iOS 上模态视图控制器的 Mac 版本），工作表控制器[self retain]在显示工作表之前以及[self release]清理和调用回调之后立即执行。这样做的目的是确保控制器对象在工作表完成之前一直存在。（工作表 IIRC 由 runloop 保留，但我还需要控制器坚持）
就像我说的那样，很少会遇到您想要的情况[self retain]，但这并非不可能。但是，作为一般经验法则，如果您认为需要[self retain]，您可能需要再考虑一下。
最简单的方法是为您的请求创建一个 iVar，在您启动它时保留该请求，并在调用最后一个委托方法时释放它。
是ARequest您创建的课程吗？它是否创建一个新线程来异步提交请求？
我曾经和你做过同样的事情。我在 NSString 上编写了一个 Category-Method 以将其发送到服务器，该服务器将打印它。在 Category-Method 中我必须调用[self retain]，以便回调方法可以是 NSString-Categroy-Method 。
我对此感到非常难过，以至于我重写了所有内容以使用由 Category-Method 访问的 Singleton。因此，Singleton 将根据需要保留字符串。