我應該在Objective-C中使用ivars嗎？

Question

我有一個正在編寫的僅使用@properties的應用程序。 我的任何類文件中都沒有聲明過一個ivar。 據我了解，@ property的引入不再需要ivars。 我是否根據最佳做法進行編碼？ 從長遠來看，這最終會在我的屁股上咬我嗎？ 我一直在閱讀關於什么是“正確”和“錯誤”的混合評論。

Answer 1

不需要實例變量不是很多。 只是不需要實例變量聲明 。 給定一個屬性和一個@synthesize語句，編譯器將負責創建實例變量以及適當的訪問器方法。

完全使用屬性沒有錯。 它們簡化了內存管理。 如果這就是您想要的，使用不帶屬性的iVars也沒有錯。 如果要使用屬性，但又不想將訪問器廣告發布到世界其他地方（即保持封裝），請考慮在類擴展（在實現文件中基本上是匿名類別）中聲明非公共屬性。

Answer 2

我通常也不會聲明ivars。 我將經常使用 @synthesize foo = foo_; 雖然在我指的是直通方法時會阻止直接訪問，反之亦然。 而且，我總是讓編譯器自動使用_前綴來合成ivar（根據被 刪除的 短語，這可以防止意外的直接訪問）。

而且，正如Caleb所說的那樣，仍然有很多ivars，除非您確實想要（除非您在標頭中公開的ivars對類的客戶沒有用，否則除非您明確聲明，否則就不要顯式聲明它們）。 ，如果您的API設計合理）。

我還發現，對“僅在init / dealloc中使用直接訪問，在其他所有地方使用setter / getter”的炒作在很大程度上被誇大了，因此，只在各處使用setter / getter。 現實情況是，如果在初始化/解除分配期間有觀察者，那么您已經准備就緒； 根據定義，對象的狀態在構造/銷毀期間是未定義的，因此觀察者可能無法正確推斷該狀態。

---

正如Caleb指出的，在init / dealloc中使用直接ivar訪問的另一個原因是，避免實現自定義setter / getter邏輯的子類可能由於init / dealloc過程中對象的未定義狀態而阻塞。

雖然這可能是正確的，但我認為以自定義行為實現設置者/獲取者是一個討厭的體系結構缺陷。 這樣做很脆弱，並且隨着時間的推移重構代碼變得更加困難。 同樣，這種自定義行為通常會依賴於對象內的其他狀態，然后這種依賴導致對狀態更改的順序依賴，而這些似乎根本不由簡單的@property聲明反映出來。

即，如果您的setter和getter編寫為foo.bar = bad; 無法隨時在foo上執行，則您的代碼將被破壞。

Answer 3

當然，使用iVars並沒有錯，但是最佳實踐現在確實要求使用@property。

Answer 4

您可能要使用ivar的一個地方是要聲明一個受保護的屬性。 您可以在.m文件中為類聲明該屬性，並使用@protected指令在.h中聲明其對應的ivar。 然后，這將使您在子類中具有受保護的訪問。 沒有其他選擇可以保護成員的訪問。