導(dǎo)語(yǔ)

單例（Singletons），是Cocoa的核心模式之一。在iOS上，單例十分常見，比如：UIApplication，NSFileManager等等。雖然它們用起來十分方便，但實(shí)際上它們有許多問題需要注意。所以在你下次自動(dòng)補(bǔ)全dispatch_once代碼片段的時(shí)候，想一下這樣會(huì)導(dǎo)致什么后果。

什么是單例

在《設(shè)計(jì)模式》一書中給出了單例的定義：

單例模式：保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。

單例模式提供了一個(gè)訪問點(diǎn)，供客戶類為共享資源生成唯一實(shí)例，并通過它來對(duì)共享資源進(jìn)行訪問，這一模式提供了靈活性。

在objective-c中，可以使用以下代碼創(chuàng)建一個(gè)單例：

+(instancetype)sharedInstance
{
 static dispatch_once_t once;
 static id sharedInstance;
 dispatch_once(&once, ^{
 sharedInstance = [[self alloc]init];
 });
 return sharedInstance;
}

當(dāng)類只能有一個(gè)實(shí)例，而且必須從一個(gè)訪問點(diǎn)對(duì)其進(jìn)行訪問時(shí)使用單例就顯得十分方便，因?yàn)槭褂脝卫ＷC了訪問點(diǎn)的唯一、一致且為人熟知。

單例中的問題

全局狀態(tài)

首先我們都應(yīng)該達(dá)成一個(gè)共識(shí)“全局可變狀態(tài)”是危險(xiǎn)的，因?yàn)檫@樣會(huì)讓程序變得難以理解和調(diào)試，就削減狀態(tài)性代碼上，面向?qū)ο缶幊虘?yīng)該向函數(shù)式編程學(xué)習(xí)。

比如下面的代碼：

@implementation Math{
 NSUInteger _a;
 NSUInteger _b;
}

-(NSUInteger)computeSum
{
 return _a + _b;
}

這段代碼想要計(jì)算_a和_B相加的和，并返回。但事實(shí)上這段代碼存在著不少問題：

• computeSum方法中并沒有把_a和_b作為參數(shù)。相比查找interface并了解哪個(gè)變量控制方法的輸出，查找implementation來了解顯得更隱蔽，而隱蔽代表著容易發(fā)生錯(cuò)誤。
• 當(dāng)準(zhǔn)備修改_a和_b的值來讓它們調(diào)用computeSum方法的時(shí)候，程序員必須清楚修改它們的值不會(huì)影響其他包含著兩個(gè)值的代碼的正確性，而在多線程的情況下作出這樣的判斷顯得尤其困難。

對(duì)比下面這段代碼：

+(NSUInteger)computeSumOf:(NSUInteger)a plus:(NSUInteger)b
{
 return a + b;
}

這段代碼中，a和b的從屬顯得十分清晰，不再需要去改變實(shí)例的狀態(tài)來調(diào)用這個(gè)方法，而且不用擔(dān)心調(diào)用這個(gè)方法的副作用。

那這個(gè)例子和單例又有什么關(guān)系呢？事實(shí)上，單例就是披著羊皮的全局狀態(tài)。一個(gè)單例可以在任何地方被使用，而且不用清晰地聲明從屬。程序中的任何模塊都可以簡(jiǎn)單的調(diào)用[MySingleton sharedInstance]，然后拿到這個(gè)單例的訪問點(diǎn)，這意味著任何和單例交互時(shí)產(chǎn)生的副作用都會(huì)有可能影響程序中隨機(jī)的一段代碼，如：

@interface MySingleton : NSObject

+(instancetype)sharedInstance;

-(NSUInteger)badMutableState;
-(void)setBadMutableState:(NSUInteger)badMutableState;

@end

@implementation ConsumerA

-(void)someMethod
{
 if([[MySingleton sharedInstance] badMutableState]){
 //do something...
 }
}

@end

@implementation ConsumerB

-(void)someOtherMethod
{
 [[MySingleton sharedInstance] setBadMutableState:0];
}

在上面的代碼中，ConsumerA和ComsumerB是程序中兩個(gè)完全獨(dú)立的模塊，但是ComsumerB中的方法會(huì)影響到ComsumerA中的行為，因?yàn)檫@個(gè)狀態(tài)的改變通過單例傳遞了過去。

在這段代碼，正是因?yàn)閱卫娜中院蜖顟B(tài)性，導(dǎo)致了ComsumerA和ComsumerB這兩個(gè)看起來似乎毫無關(guān)系的模塊之間隱含的耦合。

對(duì)象生命周期

另一個(gè)單例的主要問題是它們的生命周期。

舉個(gè)例子，假設(shè)一個(gè)app中需要實(shí)現(xiàn)能夠讓用戶看到他們的好友列表的功能，每一個(gè)好友有自己的頭像，同時(shí)我們還希望這個(gè)app能夠下載并緩存這些好友的頭像。這時(shí)候通過之前學(xué)習(xí)單例的知識(shí)，我們很可能會(huì)寫出以下的代碼：

@interface MyAppCache : NSObject

+(instancetype)sharedCMyAppCache;

-(void)cacheProfileImage:(NSData *)imageData forUserId:(NSString *)userID;
-(NSData *)cachedProfileImageForUserId:(NSString *)userId;

@end

這段代碼看起來完全沒有問題，運(yùn)行起來也很好，所以app繼續(xù)開發(fā)，直到有一天，我們決定幫app加入“登出”的功能。突然我們發(fā)現(xiàn)，用戶數(shù)據(jù)儲(chǔ)存在全局單例中。當(dāng)用戶登出的時(shí)候，我們想要把這些數(shù)據(jù)清除掉，當(dāng)新用戶登入的時(shí)候，再為他創(chuàng)建一個(gè)新的MyAppCache。

但是問題出在了單例這里，因?yàn)閱卫亩x就是：“創(chuàng)建一次，永久存活”的實(shí)例。事實(shí)上有很多方法解決上面的問題，我們也許可以在用戶登出的時(shí)候銷毀這個(gè)單例：

static MyAppCache *myAppCache;

+(instancetype)sharedMyAppCache
{
 if(!myAppCache)
 {
 myAppCache = [[self alloc] init];
 }
 return myAppCache;
}

+(void)tearDown
{
 myAppCache = nil;
}

上面的代碼扭曲了單例這個(gè)模式，但是能起到作用。

事實(shí)上的確可以使用這個(gè)方法來解決這個(gè)問題，但是代價(jià)太大了。最重要的一點(diǎn)是我們放棄了dispatch_once，而它正是保證了方法調(diào)用時(shí)候的線程安全，現(xiàn)在所有調(diào)用[MyAppCache shareMyAppCache]的代碼都會(huì)得到同一個(gè)變量，著需要清楚使用MyAppCache代碼執(zhí)行的順序。試想一下當(dāng)用戶在登出的時(shí)候碰巧后臺(tái)調(diào)用了這個(gè)方法來保存圖片。

另一方面，實(shí)行這個(gè)方法需要確保tearDown這個(gè)方法不會(huì)在后臺(tái)任務(wù)還沒執(zhí)行完成的時(shí)候調(diào)用，或者說確保執(zhí)行tearDown方法的時(shí)候后臺(tái)任務(wù)都會(huì)被取消。否則另一個(gè)新的MyAppCache將會(huì)創(chuàng)建，并把陳舊的數(shù)據(jù)保存進(jìn)去。

但是由于單例沒有明確的owner（因?yàn)閱卫约汗芾碜约旱纳芷冢N毀一個(gè)單例是非常艱難的。

所以這時(shí)你可能會(huì)想，“那就不要把MyAppCache做成單例吧！”其實(shí)問題在于一個(gè)對(duì)象的生命周期在項(xiàng)目初期可能沒有辦法很好的確定，如果假設(shè)一個(gè)對(duì)象的生命周期將會(huì)匹配整個(gè)程序的生命周期，這將會(huì)大大限制了代碼的可拓展性，當(dāng)產(chǎn)品需求改動(dòng)的時(shí)候這將會(huì)很痛苦。

所以上面的一切都是為了闡明一個(gè)觀點(diǎn)：“單例只應(yīng)該保持全局狀態(tài)，且該狀態(tài)的生命周期與程序的生命周期一致”。對(duì)于程序中已經(jīng)存在的單例，需要批判性的審閱。

不利于測(cè)試

關(guān)于這一部分原文中放到了上一章節(jié)中提及，但我認(rèn)為在軟件開發(fā)中測(cè)試是十分重要的一環(huán)，所以單獨(dú)把這一塊的內(nèi)容另開一個(gè)章節(jié)，并加入一些個(gè)人的見解。

由于單例一直在整個(gè)app的生命周期中存活著，甚至在執(zhí)行測(cè)試的時(shí)候也一直存活著，這導(dǎo)致了在一個(gè)測(cè)試或許會(huì)影響另一個(gè)測(cè)試，這是在單元測(cè)試中的大忌。
所以有必要在進(jìn)行單元測(cè)試的時(shí)候能夠有效銷毀一個(gè)單例，并保持住單例線程安全的特性。但在上文中我提到：

"但是由于單例沒有明確的owner（因?yàn)閱卫约汗芾碜约旱纳芷冢N毀一個(gè)單例是非常艱難的。"

似乎兩者在自相矛盾，其實(shí)不然，可以選擇簡(jiǎn)化單例，與其擁有各種的單例，不如只擁有一個(gè)“真正的” 單例ServiceRegistry，而把其他“潛在的”單例來被ServiceRegistry引用，這樣其他單例擁有了一個(gè)owner，能夠在進(jìn)行單元測(cè)試的時(shí)候能夠及時(shí)對(duì)單例進(jìn)行銷毀，保證了單元測(cè)試的獨(dú)立性。

另一方面，ServiceRegistry的存在使得其他“單例”不再是單例，這樣在TDD的時(shí)候會(huì)讓之前難以 mock 的單例變得更加簡(jiǎn)單的 mock 。

結(jié)論

我們都知道全局可變狀態(tài)是不好的，但是在使用單例的時(shí)候我們又不經(jīng)意地把它變成我們討厭的全局可變狀態(tài)。
在面向?qū)ο缶幊讨?，我們需要盡可能減少可變狀態(tài)的作用域，而單例與這個(gè)思想背道而馳，希望在下一次使用單例的時(shí)候能夠多想一想，考慮是否這個(gè)變量真正值得成為一個(gè)單例，如果不是，還請(qǐng)使用“依賴注入模式”來代替。

翻譯、修改自obj.io

原文鏈接：Avoiding Singleton Abuse

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論