用ARC爲什麼使用@properties了？

在非ARC代碼保留屬性中，使用self.property =語法輕鬆地爲您管理內存管理，所以我們被教導將它們用於幾乎所有的事情。用ARC爲什麼使用@properties了？

但是現在用ARC這個內存管理不再是問題，那麼使用屬性蒸發的原因是什麼？是否還有任何好的理由（顯然除了提供公共訪問實例變量）來使用屬性？

來源

2012-03-26 trapper

但是現在有了這個ARC內存管理不再是一個問題，所以不使用性質蒸發的原因嗎？是否還有任何好的原因（顯然除了提供公共訪問實例變量）以使用屬性了？

是 - 通過使用@property和@synthesized getter/setter方法，你保證：

您的getter/setter可以被子類和子類可以覆蓋存儲和/或行爲
一切仍然很好地封裝
你可以使用觀察鉤 - KVO等... - 監視內部和外部的變化
你有一個方便的位置來設置讀取和/或寫入專業版的斷點perty
如果需要暴露「僅內部」實例變量，則需要複製@property聲明本身;更少重構。
你可以利用所有的各種修改關鍵字的聲明力量 - 複製，強，弱，原子等。 - 該編譯器正在超過thime

越來越多的優勢，即使是在內部到一個類，我通常傾向於使用屬性和點語法來維護對象內的狀態。這不是普遍的真理 - 如果我的設計是暴露無論如何意味着大規模的重構，那麼我會直接操縱一些實例變量（直接操縱;根本沒有@property）。

來源

2012-03-26 17:14:06 bbum

此外，屬性還使添加複製語義和原子語義變得更加簡單和安全。另外使用@synthesize propname = ivarname創建一個名稱和一個實例變量的屬性。總是有用的。 – Cthutu 2012-03-26 17:42:57

同意，謝謝你的回答。我還想補充一點，有很多關於@property性能vs ivars的討論。我敢讓你們發現非原子性質和伊娃之間的表現差異......它可能是無法估量的微不足道的。 – 2013-08-20 20:26:09

難道你不同意在你的api中修飾符關鍵字weak，strong，atomic等對你來說是有用的標記，並且也可以讓arc本身理解你的意圖嗎？ – Jef 2016-02-23 00:52:04

我不認爲我曾經因爲內存管理而使用過屬性，我不認爲你應該這樣做。所以要回答你的問題，不，沒有理由使用除訪問實例變量之外的屬性，這本質上是它們應該首先使用的。

來源

2012-03-26 17:09:34

如果您沒有使用過屬性，那麼您可能做錯了。「有時它看起來很乏味或迂腐，但如果你持續使用訪問器方法，存儲管理問題的機會就會大大減少。如果您在整個代碼中使用實例變量的保留和釋放，那麼幾乎肯定會做錯事情。「 - 內存管理編程指南，Apple – 2012-04-24 23:39:23

@DaveBatton該引用不適用於ARC – 2012-08-02 20:28:41

@JesseGumpo同意，它不會不適用於ARC。我打算讓它適用於凱文的評論，他從來沒有「僅僅因爲內存管理而使用過屬性......」 – 2012-08-02 21:02:27

你在談論兩件不同的事情。 ARC是用於管理內存的，所以你不必擔負大量的dealloc和保留語句的負擔。

屬性讓類有機會控制/限制其內部iVars的暴露，暴露其他類與其通信/交互的API。

來源

2012-03-26 17:14:27 Gobot

除了保留，還有其他修飾符有時可能變得非常有用，例如， 'copy'將塊分配給類成員變量時，或'readonly'確保無法寫入屬性。在使用核心數據時也不要忘記'dynamic'屬性，以及在分配或檢索屬性時（定義自定義getter/setter而不使用@synthesize時）執行自定義代碼的可能性。

來源

2012-03-26 17:15:42 Amiramix

那麼使用屬性蒸發的原因是什麼？

隨着ARC使得「所有權魔術」提供給實例變量，爲什麼人會選擇在高德特性這方面的問題並蒸發。然而，許多人仍然：

原子/非原子的區別是供性質，而不是高德
靈活性，性能得到（只讀/讀+寫的區別）不適用於高德
執行能力計算和參數檢查不可用於ivars

我繼續使用屬性作爲我可以暴露給外部類或內部「兄弟」類的默認方式，因爲額外的靈活性超過了小的a運行時的附加成本。

來源

2012-03-26 17:16:52 dasblinkenlight

用ARC爲什麼使用@properties了？

回答

相關問題