24H免费课程咨询  TEL:13401595960   QQ:1870218756  微信:13401595960(李老师)

东方博宜

网站首页 > 软件开发资讯 > IOS开发

【常州iOS开发培训班】iOS开发 单例使用问题

2018-05-13 22:02:54 东方博宜 阅读


什么是单例


在《设计模式》一书中给出了单例的定义:


单例模式:保证一个类仅有一个实例,并提供一个访问它的全局访问点。


单例模式提供了一个访问点,供客户类为共享资源生成唯一实例,并通过它来对共享资源进行访问,这一模式提供了灵活性。


在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做成单例吧!”其实问题在于一个对象的生命周期在项目初期可能没有办法很好的确定,如果假设一个对象的生命周期将会匹配整个程序的生命周期,这将会大大限制了代码的可拓展性,当产品需求改动的时候这将会很痛苦。


所以上面的一切都是为了阐明一个观点:“单例只应该保持全局状态,且该状态的生命周期与程序的生命周期一致”。对于程序中已经存在的单例,需要批判性的审阅。

常州东方博宜是一家专注IT,互联网,电脑方面的顶尖培训机构,欢迎社会及院校有志互联网营销,搜索引擎营销的人士,来东方博宜报名学习,互相交流。

常州东方博宜地址:常州天宁区延陵西路2号工人文化宫5号楼

 2.新北区太湖东路9-4号常州创意园E12


Powered by 东方博宜教育咨询江苏有限公司  ©2008-2018 www.czos.cn