前言

為什麼不要在init和dealloc方法中呼叫getter和setter:
Apple在Mac與iOS中關於記憶體管理的開發文件中，有一節的題目為：“Don’tUse Accessor Methods in Initializer Methods and dealloc”，文中說：“Theonly places you shouldn’t use accessor methods to set an instancevariable are in initializer methods anddealloc.”但是並沒有解釋為什麼。網上搜索了幾篇國內國外的文章和一些大V的部落格，希望此文能詳盡大家的疑惑，未盡之處請留言指正。

 

為什麼不能在init中呼叫accessor

案例一

下面這則程式碼說明了一種可能會引起錯誤的情況：現有兩個類BaseClass和SubClass，SubClass繼承自BaseClass。父類有一個value屬性（子類自然也會整合該屬性）。如果在父類的init（或其他初始化構造方法）中使用了value的setter，子類也重寫了value的setter，那麼就會出現問題。原因如下：子類呼叫init（或其他初始化構造方法）初始化物件時候，子類的init會首先呼叫父類的init（self = [super init]），這樣就會調到父類的init方法裡，而我們在父類的init方法裡呼叫了setter給value屬性賦值。父類會直接呼叫子類重寫的那個setter(因為子類重寫了value的setter)。此時，子類物件還沒有初始化好，但子類value的setter先卻先於子類自己的init程式碼呼叫(因為此時子類的init方法還沒有return self

)，就有可能會出現問題。如果我們在子類的setter方法中做了其他操作，比如修改了某個例項變數的值，那麼就會出錯，因為此時self還沒有初始化好。
造成這個問題的原因有兩個：一就是在父類的init使用了setter；二是子類重寫了setter，導致在父類init時就會呼叫子類重寫的setter，萬一重寫的setter中進行了一些子類特有的操作就可能會出現問題，比如，給子類的某個屬性賦值失敗，因為此時子類物件self還沒有初始化完成。

案例二

如果在父類的init方法中使用了value的setter，同時也在父類寫了setter。當子類初始化時會先呼叫父類的init方法，即self = [super init]

,由於父類中使用了value的setter，那麼父類的init又會調到value的setter，如果setter中做了其他的操作，比如傳送一個網路請求，那麼此時就有可能出現問題。而當子類物件通過setter給value賦值時，又會呼叫父類的setter。那麼相當於父類的setter被呼叫了兩次，傳送了兩次相同的網路請求。

init call accessor Example:

@interface BaseClass : NSObject
@property(nonatomic) NSString* info;
@end

@implementation BaseClass
- (instancetype)init {  
    if ([super init]) {
        self.info = @"baseInfo"; 
    } 
    return self;
}
@end

@interface SubClass : BaseClass
@end
@interface SubClass ()
@property (nonatomic) NSString* subInfo;
@end

@implementation SubClass
- (instancetype)init {
     if (self = [super init]) {
         self.subInfo = @"subInfo"; 
    } 
    return self;
}

- (void)setInfo:(NSString *)info {
    [super setInfo:info]; 
    NSString* copyString = [NSString stringWithString:self.subInfo]; NSLog(@"%@",copyString);
}
@end
 

在SubClass的例項物件銷燬時，首先呼叫子類的dealloc，再呼叫父類的dealloc（這與init初始化是相反的，且ARC中不需要我們手動呼叫[super dealloc]）。如果父類在dealloc時呼叫了accessor 並且該accessor被子類重寫，就會呼叫到子類的accessor。而此時子類的dealloc已經被呼叫了，基於其完整的假設已經不成立，那麼再執行子類的程式碼會存在一定風險，如上例就會崩潰。

 

為什麼不能在dealloc中呼叫accessor

還是基於子類重寫了父類的value屬性這一前提，在子類物件銷燬時，首先呼叫子類的dealloc，最後呼叫父類的dealloc（這與init初始化方法是相反的，且ARC中不需要我們手動呼叫[super dealloc]）。如果父類在dealloc中呼叫了value的accessor且該accessor被子類重寫，就會調到子類的accessor。但此時子類已經釋放(因為先呼叫子類的dealloc，後呼叫父類的dealloc)，所以就會出現錯誤甚至崩潰。
dealloc call accessor example

@interface BaseClass : NSObject
@property(nonatomic) NSString* info;
@end

- (void)dealloc {
    self.info = nil;
}
@end
 
@interface SubClass : BaseClass
@property (nonatomic) NSString* debugInfo;
@end

@implementation SubClass

- (instancetype)init {
    if (self = [super init]) {
        _debugInfo = @"This is SubClass";
    }
    return self;
}
- (void)setInfo:(NSString *)info {
    NSLog(@"%@",[NSString stringWithString:self.debugInfo]);
}
- (void)dealloc {
    _debugInfo = nil;
}
@end 

在SubClass的例項物件銷燬時，首先呼叫子類的dealloc，再呼叫父類的dealloc（這與init初始化是相反的，且ARC中不需要我們手動呼叫[super dealloc]）。如果父類在dealloc時呼叫了accessor 並且該accessor被子類重寫，就會呼叫到子類的accessor。而此時子類的dealloc已經被呼叫了，基於其完整的假設已經不成立，那麼再執行子類的程式碼會存在一定風險，如上例就會崩潰。

另外，在《Effective Objective-C 2.0 編寫高質量iOS與OS X程式碼的52個有效方法》的第31條——在dealloc方法中只釋放引用並解除監聽一節文中，作者也提到了下面一段話：在dealloc裡不要呼叫屬性的存取方法，因為有人可能會覆寫這些方法，並於其中做一些無法再回收階段安全執行的操作（上面已經提到）。此外，屬性可能正處於“鍵值觀察”(Key-Value Observation，KVO)機制的監控之下，該屬性的觀察者(Observer)可能會在屬性值改變時“保留”或使用這個即將回首的物件。這種做法會令執行期系統的狀態完全失調，從而導致一些莫名其妙的錯誤。

結論

綜上，不能在init和dealloc中使用accessor的原因是由於面向物件的繼承、多型特性與accessor可能造成的副作用聯合導致的。繼承和多型導致在父類的實現中呼叫accessor可能導致呼叫到子類重寫的accessor，而此時子類部分並未完全初始化或已經銷燬，導致原有的假設不成立，從而出現一系列的邏輯問題甚至崩潰。為了更清晰地闡述，以下分別從init和dealloc上舉例說明。

結尾

在init和dealloc中使用accessor是存在風險的。但這並不代表百分之百的崩潰或者百分之百的錯誤。從目前的實驗來看，當存在繼承時，在init或者dealloc方法中使用accessor會存在很高的風險，此時我們可要小心了。不過，在公司專案中，還是建議大家不要鋌而走險，即使現在程式碼沒有問題，難保將來維護或擴充套件時會出現問題。只有將蘋果所說的Don’t Use Accessor Methods in Initializer Methods and dealloc當作一條程式設計規範，才能從根本上規避這個問題。不過，有些情況我們必須破例，必須訪問accessor，比如：待初始化的例項變數宣告在超類中，而我們又無法在子類中訪問此例項變數的話，那麼我們只能通過setter來對例項變數賦值。又比如：如果一個例項變數是lazy的（懶載入），這種情況必須通過getter方法訪問屬性，否則無法給例項變數賦值。
所以，萬事無絕對，我們只有理解了為什麼不能在init和dealloc方法中使用accessor才能在各種情況下游刃有餘。