除非你做一些瘋狂的可能性是額外的保留/釋放應該不會造成問題。
因此有一個與它存儲在伊娃沒有真正的問題...
更好的理由這樣做不會保存您的打字聲,而是以提高類的可測試性/可重用性。通過使它成爲一個伊娃,它允許你注入一個不同的類來改變行爲。
我會考慮的訪問時默認給我單身,但還是讓我來注入不同的類,如果我選擇這樣的
- (SingletonClass *)singletonObj;
{
return _singletonObj = _singletonObj ?: [SingletonClass sharedInstance];
}
更新:
這也是值得我們思考的「爲什麼你會使用這個與使用伊娃不同的單身?」。如果你在整個班級中使用它,就像是一個伊娃,那麼你爲什麼要以完全不同的方式訪問它?
例如,當我使用managedObjectContext
時,我的整個應用程序中只有一個。很多人使用應用程序委託作爲單例,並以此方式訪問它,但我更願意將它作爲ivar傳遞。從概念上來說,managedObjectContext
只是另一個對象,我像其他任何伊娃一樣使用,那麼爲什麼我必須在思維上切換如何訪問它?
這是不好的
[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
好
self.managedObjectContext;
現在,這給了我兩個優點。
如果我的類與調用[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
散落那麼就很難撕了這個項目,並將其放置在另一個沒有危險的搜索和替換。如果我在一個地方訪問「訪問者」,那麼我只有一個地方可以更改代碼。
在我的生產應用程序中,我可能希望我的數據是持久性的,所以我會給該對象訪問持有存儲的managedObjectContext
,而在我的測試中,我不希望狀態在測試之間持續存在,所以我會改爲給對象一個非持久性商店。
爲什麼要將它作爲任何對象的屬性或iVar?關鍵是你可以從任何地方訪問它們! – CodaFi
由於我上面提到的原因,所以我不必每次都輸入[SingletonClass sharedInstance]。 – BeachRunnerFred
但它沒有任何意義。事實上,你保留了一些無法發佈的東西,甚至根本不存儲它,這簡直太可笑了。如果你真的厭倦了打字,只需將'[SingletonClass sharedInstance]'映射到一些縮短的宏。或者,如果您實際上訪問的是單身人士,請考慮將其分解爲更小,更易於管理的對象。另外,上面的代碼將它存儲爲***屬性***而不是iVar。 – CodaFi