iOS单例（方便copy）

#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等,它们用起来十分方便.
在《设计模式》一书中给出了单例的定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

关键代码：

+(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相加的和，并返回。
}

1. computeSum方法中并没有把_a和_b作为参数。相比查找interface并了解哪个变量控制方法的输出，查找implementation来了解显得更隐蔽，而隐蔽代表着容易发生错误。(此处不能完全理解，会出现的错误)
2. 当准备修改_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做成单例吧！”其实问题在于一个对象的生命周期在项目初期可能没有办法很好的确定，如果假设一个对象的生命周期将会匹配整个程序的生命周期，这将会大大限制了代码的可拓展性，当产品需求改动的时候这将会很痛苦。
所以上面的一切都是为了阐明一个观点：“单例只应该保持全局状态，且该状态的生命周期与程序的生命周期一致”。

END

---

不利于测试

。。。。。。。。。。

单例问题