是否省略屬性的ivars聲明可能會導致故障或泄漏？

我開始學習和開發iOS4，所以我只是跳過舊的伊娃聲明慣例，並開始使用純屬性，甚至沒有聲明ivars。一切都很順利，我甚至在應用程序商店發佈了我的第一個自制應用程序。但接着在我的開發公司，人們告訴我他們仍在使用舊的慣例，並且聲明ivars的名字是下劃線，使用屬性併合成它們（參見最後的例子）。他們還表示，只有當需要外部訪問ivars時才使用屬性，而對於內部訪問，他們使用直接ivars（用於定製類）。我被告知，他們這樣做是因爲他們遇到了一些奇怪的泄漏，有時出現在使用自定義類並且無視viewDidUnload中的屬性時（因爲將nil設置爲屬性有時不會釋放那些ivar對象）是否省略屬性的ivars聲明可能會導致故障或泄漏？

只是想知道爲什麼我應該使用伊娃聲明時使用屬性和綜合做所有需要的東西。我甚至可以在dealloc中直接使用他們的名字直接訪問ivars。那麼，有沒有人遇到過這個問題，或者你們中的很多人仍然堅持舊的聲明慣例？

@interface ContactModel : NSObject { 

    NSString *_firstName; 
} 

@property (nonatomic, retain) NSString *firstName; 

@end 

@implementation ContactModel 

@synthesize firstName = _firstName; 

-(void)dealloc{ 
    [_firstName release]; 
    [super dealloc]; 
} 
@end

還應該注意的是，Apple在生成主應用程序委託類文件併合成window = _window時仍使用舊的聲明樣式。嗯，目前，我對於應該採用什麼樣的約定有點困惑，所以歡迎任何想法:)

來源

2011-09-26 Centurion

可能重複http://stackoverflow.com/questions/3238009/property -declaration-and-automatic-backing-storage-allocation） –

在現代運行時你不需要伊娃聲明，但綜合a = _a仍然有用區分self.a（訪問者）和_a（直接訪問）。如果@ property/@ synthesize泄漏，我認爲我們現在應該知道它。

使用ivars而不是屬性的AFAIK只有在您需要@protected訪問（僅限訪問子類）或支持舊運行時時纔有用。

在dealloc中，您應該直接釋放屬性，無論您是使用伊娃聲明還是@properties，還可以選擇you can nil或not。

來源

2011-09-26 06:59:57 Jano

謝謝。但是，當a = _a有用時，我的意思是訪問self.a和直接訪問_a的用例是什麼？理論上，你應該總是使用封裝和保護ivars免於直接訪問（至少理論上，因爲我知道所有ivars都非常公開） – Centurion

使用下劃線只是一個命名約定，表明_a是直接訪問。如果您希望在訪問器中避免引起諸如觸發通知等副作用的代碼，則可以使用直接訪問。 – Jano

如果一個對象註冊到通知，那麼使用直接訪問進行更改會避免通知？我一直認爲這不取決於使用格式。 – Centurion

我喜歡'老方法'，因爲我贊成一致性和（更重要的）封裝。

一致性

個人而言，我只是想通過尋找一處對象的規模和複雜性的一個好主意。

例子：當你實現dealloc時，你更喜歡引用多個地方嗎？不是我。它比必要的更復雜。我不想通過從所有ivars和屬性創建一個集合來清理我需要清理的內容。單獨的屬性是不夠的，因爲它們最終還是在多個地方（界面，私人類別）= \

所以更小的邪惡imo是聲明ivars，所以一切都在一個地方，你有一個快速參考對象的複雜性（以及一些代碼生成器的良好輸入）。

封裝

，當你看到一個程序，其中最對象的實例變量/屬性可見，讀/寫......這不是OOD，它是一個爛攤子。當你需要禮貌地描述它時，它是反模式'Object Orgy'。不幸的是，它在objc程序中比較常見（部分是由於語言/運行時限制）。

具有前綴下劃線的ivars：個人而言，我不在objc中使用該約定。如果這就是他們的代碼是如何編寫的，那就和它一起去吧（沒什麼大不了的）。

他們還表示，他們只在需要外部訪問ivars時才使用屬性，而對於內部訪問，他們使用直接ivars（對於自定義類）。

right - 這裏是封裝輸入圖片的嘗試。去與它並且擁抱適當的封裝。

有人告訴我，他們這樣做是因爲他們遇到一些奇怪的泄漏，在使用自定義類和nil'ying他們viewDidUnload性質（因爲設置零到性能有時不釋放那些伊娃時，有時會出現物體）

理想情況下，它們會爲您提供更好的解釋（並在當時得到了具體問題的根源）。

他們的神祕程序很可能與其成員（數據），界面及其執行沒有明確的區別。當這些重疊時，失去所有權的情況並不少見。這種情況是一個混亂和/或執行超出預期的普遍跡象。如果您正確組織/編寫課程，ivar /財產跟蹤是非常簡單的（大概他們通過支持封裝來取得進展）。受保護的是默認的可見性;我建議私人作爲您的默認。

只是想知道爲什麼我應該打擾使用伊娃聲明時使用屬性和綜合做所有需要的東西。我甚至可以在dealloc中直接使用他們的名字直接訪問ivars。那麼，有沒有人遇到過這個問題，或者你們中的很多人仍然堅持舊的宣言召集？

是精心設計不是由數據斑點的（有公開或屬性訪問變量）的程序。
在大多數情況下，狀態（例如ivars）不應該直接映射到接口。
保持您的數據和對他人隱藏的阻礙。
即使'私人'屬性也可能是錯誤的一個簡單來源（它們的選擇器可能會被執行或被覆蓋）。
當private是您的默認設置並且ivar在外部是真正無法訪問時，您可以減少的複雜性。

所以...我看到它，因爲他們正在提出這個要求，通過減少外部暴露於狀態並最終降低程序的複雜性來簡化您的生活。他們承認在過去遇到過問題，他們試圖使用封裝來降低複雜性和出錯的機率。對他們有好處。

我知道，有些程序員只是喜歡一切公開可見的和可變的 - 編寫程序來支持複雜的該級別是不能有效利用的時間，而現實情況是，大多數人誰做寫方式沒有足夠的遠見或耐心來正確地寫出這樣一個規定，這會讓別人頭疼。當然，它可能在過去對你有用，但它是一種天真的方法，當你與一個團隊合作時，你沒有寫出所有程序的樂趣。因此，你不能假設他們已經閱讀並理解你所寫的每一個程序的全部內容。

通過隱藏你所能做到的事情來使你的程序變得用戶/防錯，並使它們與你團隊的風格保持一致。

（目前在技術上一些額外的好處，我將在這裏就不詳細介紹）

[財產申報和自動備份存儲分配]（的

來源

2011-09-26 08:26:34 justin

很好的答案。我不知道爲什麼當人們開始在Objc編程時，他們忘記了封裝的一切 – williamb

是否省略屬性的ivars聲明可能會導致故障或泄漏？

回答

相關問題