除非你做一些疯狂的事情,否则额外的保留/释放应该不会引起任何问题。
因此,将其存储在 ivar 中没有真正的问题......
这样做的更好理由不是节省您的打字,而是提高类的可测试性/可重用性。通过使其成为 ivar,它允许您注入不同的类来改变行为。
我会考虑制作一个访问器,默认情况下会给我单例,但如果我这样选择,仍然允许我注入不同的类
- (SingletonClass *)singletonObj;
{
return _singletonObj = _singletonObj ?: [SingletonClass sharedInstance];
}
更新:
还值得思考“为什么要使用这个单例与使用 ivar 不同?”。如果您在整个课堂上都像使用 ivar 一样使用它,那么为什么要以完全不同的方式访问它呢?
例如,当我经常使用 a 时managedObjectContext
,我的整个应用程序中只有一个。很多人将应用程序委托用作单例并以这种方式访问它,但我更喜欢将它作为 ivar 传递。从概念上讲,这managedObjectContext
只是我像任何其他 ivar 一样使用的另一个对象,所以为什么我必须在心理上改变我访问它的方式?
这是不好的
[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
好的
self.managedObjectContext;
现在这给了我两个好处。
如果我的班级到处都是调用,[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
那么很难将其从这个项目中剥离出来并将其放在另一个项目中,而无需进行冒险的搜索和替换。如果我在“访问器”的一个地方访问单例,那么我只有一个地方可以更改代码。
在我的生产应用程序中,我可能希望我的数据是持久的,所以我会给对象访问一个managedObjectContext
带有持久存储的对象,而在我的测试中,我不希望在测试之间保持状态,所以我会给对象一个非持久的而是存储。