翻譯狸驳、修改自obj.io
原文鏈接：Avoiding Singleton Abuse

導(dǎo)語

單例（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è)單例可以在任何地方被使用，而且不用清晰地聲明從屬捍壤。程序中的任何模塊都可以簡單的調(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)存在的單例抹腿，需要批判性的審閱。

不利于測試

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

由于單例一直在整個(gè)app的生命周期中存活著肩祥，甚至在執(zhí)行測試的時(shí)候也一直存活著，這導(dǎo)致了在一個(gè)測試或許會(huì)影響另一個(gè)測試微渠，這是在單元測試中的大忌搭幻。

所以有必要在進(jìn)行單元測試的時(shí)候能夠有效銷毀一個(gè)單例，并保持住單例線程安全的特性逞盆。但在上文中我提到：

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

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

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

結(jié)論

我們都知道全局可變狀態(tài)是不好的蝇恶，但是在使用單例的時(shí)候我們又不經(jīng)意地把它變成我們討厭的全局可變狀態(tài)拳魁。

在面向?qū)ο缶幊讨校覀冃枰M可能減少可變狀態(tài)的作用域撮弧，而單例與這個(gè)思想背道而馳潘懊，希望在下一次使用單例的時(shí)候能夠多想一想姚糊，考慮是否這個(gè)變量真正值得成為一個(gè)單例，如果不是授舟，還請(qǐng)使用“依賴注入模式”來代替救恨。

想了解更多內(nèi)容可以查看我的主頁