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

導語

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

什么是單例

在《設計模式》一書中給出了單例的定義：

單例模式：保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。

單例模式提供了一個訪問點，供客戶類為共享資源生成唯一實例，并通過它來對共享資源進行訪問，這一模式提供了靈活性。

在objective-c中，可以使用以下代碼創建一個單例：

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

當類只能有一個實例，而且必須從一個訪問點對其進行訪問時使用單例就顯得十分方便，因為使用單例保證了訪問點的唯一、一致且為人熟知。

單例中的問題

全局狀態

首先我們都應該達成一個共識“全局可變狀態”是危險的，因為這樣會讓程序變得難以理解和調試，就削減狀態性代碼上，面向對象編程應該向函數式編程學習。

比如下面的代碼：

@implementation Math{
    NSUInteger _a;
    NSUInteger _b;
}

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

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

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

對比下面這段代碼：

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

這段代碼中，a和b的從屬顯得十分清晰，不再需要去改變實例的狀態來調用這個方法，而且不用擔心調用這個方法的副作用。

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

@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是程序中兩個完全獨立的模塊，但是ComsumerB中的方法會影響到ComsumerA中的行為，因為這個狀態的改變通過單例傳遞了過去。

在這段代碼，正是因為單例的全局性和狀態性，導致了ComsumerA和ComsumerB這兩個看起來似乎毫無關系的模塊之間隱含的耦合。

對象生命周期

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

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

@interface MyAppCache : NSObject

+(instancetype)sharedCMyAppCache;

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

@end

這段代碼看起來完全沒有問題，運行起來也很好，所以app繼續開發，直到有一天，我們決定幫app加入“登出”的功能。突然我們發現，用戶數據儲存在全局單例中。當用戶登出的時候，我們想要把這些數據清除掉，當新用戶登入的時候，再為他創建一個新的MyAppCache。

但是問題出在了單例這里，因為單例的定義就是：“創建一次，永久存活”的實例。事實上有很多方法解決上面的問題，我們也許可以在用戶登出的時候銷毀這個單例：

static MyAppCache *myAppCache;

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

+(void)tearDown
{
    myAppCache = nil;
}

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

事實上的確可以使用這個方法來解決這個問題，但是代價太大了。最重要的一點是我們放棄了dispatch_once，而它正是保證了方法調用時候的線程安全，現在所有調用[MyAppCache shareMyAppCache]的代碼都會得到同一個變量，著需要清楚使用MyAppCache代碼執行的順序。試想一下當用戶在登出的時候碰巧后臺調用了這個方法來保存圖片。

另一方面，實行這個方法需要確保tearDown這個方法不會在后臺任務還沒執行完成的時候調用，或者說確保執行tearDown方法的時候后臺任務都會被取消。否則另一個新的MyAppCache將會創建，并把陳舊的數據保存進去。

但是由于單例沒有明確的owner（因為單例自己管理自己的生命周期），銷毀一個單例是非常艱難的。

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

所以上面的一切都是為了闡明一個觀點：“單例只應該保持全局狀態，且該狀態的生命周期與程序的生命周期一致”。對于程序中已經存在的單例，需要批判性的審閱。

不利于測試

關于這一部分原文中放到了上一章節中提及，但我認為在軟件開發中測試是十分重要的一環，所以單獨把這一塊的內容另開一個章節，并加入一些個人的見解。

由于單例一直在整個app的生命周期中存活著，甚至在執行測試的時候也一直存活著，這導致了在一個測試或許會影響另一個測試，這是在單元測試中的大忌。

所以有必要在進行單元測試的時候能夠有效銷毀一個單例，并保持住單例線程安全的特性。但在上文中我提到：

"但是由于單例沒有明確的owner（因為單例自己管理自己的生命周期），銷毀一個單例是非常艱難的。"

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

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

結論

我們都知道全局可變狀態是不好的，但是在使用單例的時候我們又不經意地把它變成我們討厭的全局可變狀態。

在面向對象編程中，我們需要盡可能減少可變狀態的作用域，而單例與這個思想背道而馳，希望在下一次使用單例的時候能夠多想一想，考慮是否這個變量真正值得成為一個單例，如果不是，還請使用“依賴注入模式”來代替。

想了解更多內容可以查看我的主頁