#import "Singleton.h"
@implementation Singleton
static Singleton* _instance = nil;
+(instancetype) shareInstance
{
static dispatch_once_t onceToken ;
dispatch_once(&onceToken, ^{
_instance = [[super allocWithZone:NULL] init] ;
}) ;
return _instance ;
}
+(id) allocWithZone:(struct _NSZone *)zone
{
return [Singleton shareInstance] ;
}
-(void)test
{
NSLog(@"SAMLI");
}
@end
單例（Singletons）野芒，是Cocoa的核心模式之一缕允。在iOS上旁趟，單例十分常見，比如：UIApplication限煞，NSFileManager等,它們用起來十分方便.
在《設(shè)計模式》一書中給出了單例的定義：保證一個類僅有一個實例抹恳，并提供一個訪問它的全局訪問點。
關(guān)鍵代碼：
+(instancetype)sharedInstance
{
static dispatch_once_t once;
static id sharedInstance;
dispatch_once(&once, ^{
sharedInstance = [[self alloc]init];
});
return sharedInstance;
}
單例中的問題
全局狀態(tài)
首先我們都應(yīng)該達(dá)成一個共識“全局可變狀態(tài)”是危險的署驻，因為這樣會讓程序變得難以理解和調(diào)試奋献，就削減狀態(tài)性代碼上健霹，面向?qū)ο缶幊?/code>應(yīng)該向函數(shù)式編程學(xué)習(xí)。
@implementation Math{
NSUInteger _a;
NSUInteger _b;
}
-(NSUInteger)computeSum
{
return _a + _b;//這段代碼想要計算_a和_B相加的和瓶蚂，并返回糖埋。
}
-
computeSum方法中并沒有把_a和_b作為參數(shù)。相比查找interface并了解哪個變量控制方法的輸出窃这，查找implementation來了解顯得更隱蔽瞳别，而隱蔽代表著容易發(fā)生錯誤。(此處不能完全理解杭攻，會出現(xiàn)的錯誤) - 當(dāng)準(zhǔn)備修改
_a和_b的值來讓它們調(diào)用computeSum方法的時候祟敛，程序員必須清楚修改它們的值不會影響其他包含著兩個值的代碼的正確性，而在多線程的情況下作出這樣的判斷顯得尤其困難朴上。(容易出現(xiàn)錯誤)
+(NSUInteger)computeSumOf:(NSUInteger)a plus:(NSUInteger)b
{
return a + b;
}
a和b的從屬顯得十分清晰，不再需要去改變實例的狀態(tài)來調(diào)用這個方法卒煞，而且不用擔(dān)心調(diào)用這個方法的副作用痪宰。
單例 就是披著羊皮的全局狀態(tài)。一個單例可以在任何地方被使用畔裕，而且不用清晰地聲明從屬衣撬。程序中的任何模塊都可以簡單的調(diào)用[MySingleton sharedInstance]，然后拿到這個單例的訪問點扮饶，這意味著任何和單例交互時產(chǎn)生的副作用都會有可能影響程序中隨機的一段代碼.
@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中的行為甜无，因為這個狀態(tài)的改變通過單例傳遞了過去扛点。正是因為單例的全局性和狀態(tài)性，導(dǎo)致了ComsumerA和ComsumerB這兩個看起來似乎毫無關(guān)系的模塊之間隱含的耦合岂丘。
對象生命周期
單例的另一哥問題是它們的生命周期
假設(shè)一個app中需要實現(xiàn)能夠讓用戶看到他們的好友列表的功能陵究，每一個好友有自己的頭像，同時我們還希望這個app能夠下載并緩存這些好友的頭像奥帘。
這時候通過之前學(xué)習(xí)單例的知識铜邮，我們很可能會寫出以下的代碼：
@interface MyAppCache : NSObject
+(instancetype)sharedCMyAppCache;
-(void)cacheProfileImage:(NSData *)imageData forUserId:(NSString *)userID;
-(NSData *)cachedProfileImageForUserId:(NSString *)userId;
@end
這段代碼看起來完全沒有問題，運行起來也很好寨蹋，所以app繼續(xù)開發(fā)松蒜，直到有一天，我們決定幫app加入“登出”的功能已旧。突然我們發(fā)現(xiàn)秸苗，用戶數(shù)據(jù)儲存在全局單例中。
當(dāng)用戶登出的時候运褪，我們想要把這些數(shù)據(jù)清除掉难述，當(dāng)新用戶登入的時候萤晴，再為他創(chuàng)建一個新的MyAppCache。
問題出在了單例這里胁后，單例的定義就是：“創(chuàng)建一次店读，永久存活”的實例。事實上有很多方法解決上面的問題攀芯，我們也許可以在用戶登出的時候銷毀這個單例：
static MyAppCache *myAppCache;
+(instancetype)sharedMyAppCache
{
if(!myAppCache)
{
myAppCache = [[self alloc] init];
}
return myAppCache;
}
+(void)tearDown
{
myAppCache = nil;
}
//代碼扭曲了單例這個模式意義屯断，但是能起到作用。
//事實上的確可以使用這個方法來解決這個問題侣诺，但是代價太大了.
最重要的是我們放棄了dispatch_once殖演，而它正是保證了方法調(diào)用時候的線程安全，現(xiàn)在所有調(diào)用[MyAppCache shareMyAppCache]的代碼都會得到同一個變量年鸳，著需要清楚使用MyAppCache代碼執(zhí)行的順序趴久。
試想一下當(dāng)用戶在登出的時候碰巧后臺調(diào)用了這個方法來保存圖片。
另一方面搔确，實行這個方法需要確保 tearDown這個方法不會在后臺任務(wù)還沒執(zhí)行完成的時候調(diào)用彼棍，或者說確保執(zhí)行tearDown方法的時候后臺任務(wù)都會被取消。否則另一個新的MyAppCache將會創(chuàng)建膳算，并把陳舊的數(shù)據(jù)保存進去座硕。
但是由于單例沒有明確的owner（因為單例自己管理自己的生命周期），銷毀一個單例是非常艱難的涕蜂。
所以這時你可能會想华匾，“那就不要把MyAppCache做成單例吧！”其實問題在于一個對象的生命周期在項目初期可能沒有辦法很好的確定机隙，如果假設(shè)一個對象的生命周期將會匹配整個程序的生命周期蜘拉，這將會大大限制了代碼的可拓展性，當(dāng)產(chǎn)品需求改動的時候這將會很痛苦有鹿。
所以上面的一切都是為了闡明一個觀點：“單例只應(yīng)該保持全局狀態(tài)诸尽，且該狀態(tài)的生命周期與程序的生命周期一致”。
END
不利于測試
印颤。您机。。年局。际看。。矢否。仲闽。。僵朗。
