ios - 为什么 myInstance = nil 而不是 self.myInstance = nil？
<p><p>我为什么要使用(在我的 dealloc 方法中)？</p>
<ol>
<li><code></code> 而不是 <code></code></li>
<li><code>myInstance = nil</code> 而不是 <code>self.myInstance = nil</code></li>
</ol>
<p>虽然我们使用 <code>self.myInstance = [[ init] autorelease]</code> 而不是 <code>myInstance = [[ init] autorelease]</code>？</p>
<p>这些做法来 self 在网络上看到的大量示例。</p></p>
<br><hr><h1><strong>Best Answer-推荐答案</ strong></h1><br>
<p><blockquote>
<p>1) instead of </p>
</blockquote>
<p>更喜欢前者。</p>
<p><code>self.myInstance</code> 的返回值是在子类重写了<code>myInstance</code> 方法时由实现定义的。您对在 dealloc 期间构造对象的接口(interface)的行为不感兴趣(因为子类可能会覆盖并返回除您的 ivar 之外的其他内容)。</p>
<p>你对 dealloc 感兴趣的是在你的对象被销毁之前释放你拥有的引用。如果子类覆盖了 <code>myInstance</code>，那么它可以:</p>
<p>a) 返回一个已经发布的 ivar(在子类中声明)</p>
<p>或</p>
<p>b) 覆盖的实现可能会返回一个新创建的自动释放对象</p>
<p>a 或 b 都可能导致过度释放和崩溃(假设其他所有内容都正确保留/释放)。这也说明了为什么在释放 ivar 后应该将 nil 分配给它。</p>
<p>这也是如何触发对象复活的经典示例。当您调用的 getter/setter 的实现在其已被释放后重新创建其状态时，就会发生对象复活。最小的攻击性副作用会导致无害的泄漏。</p>
<blockquote>
<p>2) myInstance = nil instead of self.myInstance = nil</p>
</blockquote>
<p>再次，更喜欢前者。</p>
<p>正式的回应看起来很像对#1的回应——基本原理、副作用和危险也适用于此。</p>
<p>最安全的处理方法是直接访问 ivar:</p>
<pre><code>, myInstance = nil;
</code></pre>
<p>因为可能存在难以重现的非常糟糕的副作用(崩溃、泄漏、复活)。</p>
<p>这些危险可以很容易地避免，并且您的代码将更容易维护。另一方面，如果人们在使用您的程序时遇到副作用，他们可能会尽可能避免(重新)使用它。</p>
<p>祝你好运</p></p>
<p style="font-size: 20px;">关于ios - 为什么 myInstance = nil 而不是 self.myInstance = nil？，我们在Stack Overflow上找到一个类似的问题：
<a href="https://stackoverflow.com/questions/4895189/" rel="noreferrer noopener nofollow" style="color: red;">
https://stackoverflow.com/questions/4895189/
</a>
</p>
页:
[1]