我正在为现有的单例类创建一个包装器类。因为我会多次访问单例,所以我想将它作为 ivar 存储在我的包装类中......
@interface WrapperClass ()
@property (nonatomic, strong) SingletonClass singletonObj;
@end
...这样我就不必经常编写 [[SingletonClass sharedInstance] methodName]
。相反,我可以编写 [singletonObj methodName]
。我觉得它更干净。
我是 iOS 开发的新手,所以我想知道这种方法是否存在根本性错误。
此外,对于 ARC,我应该使用强引用存储单例吗?
最佳答案
除非你做一些疯狂的事情,否则额外的保留/释放应该不会造成问题。
因此将它存储在 ivar 中没有真正的问题......
这样做的一个更好的理由不是为了节省您的输入,而是为了提高类的可测试性/可重用性。通过将其设为 ivar,您可以在其中注入(inject)不同的类以更改行为。
我会考虑制作一个默认情况下给我单例但仍然允许我注入(inject)不同类的访问器,如果我这样选择的话
- (SingletonClass *)singletonObj;
{
return _singletonObj = _singletonObj ?: [SingletonClass sharedInstance];
}
更新:
同样值得思考的是“为什么要让使用这个单例与使用 ivar 不同?”。如果您在整个类里面都像使用 ivar 一样使用它,那么为什么要以完全不同的方式访问它?
例如,当我使用 managedObjectContext
时,我的整个应用程序中通常只有一个。很多人将应用程序委托(delegate)作为单例使用并以这种方式访问它,但我更喜欢将它作为 ivar 传递。从概念上讲,managedObjectContext
只是我像其他任何 ivar 一样使用的另一个对象,所以我为什么要在心理上改变访问它的方式?
这很糟糕
[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
好
self.managedObjectContext;
现在这给了我两个优势。
如果我的类(class)充斥着对
[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
的调用,那么很难将其从该项目中删除并放置在另一个没有风险的搜索和替换中。如果我在一个地方访问单例“访问器”,那么我只有一个地方可以更改代码。在我的生产应用程序中,我可能希望我的数据是持久的,所以我会让对象访问具有持久存储的
managedObjectContext
,而在我的测试中我不想要状态在测试之间持久化,所以我会给对象一个非持久性存储。
关于ios - 我应该将单例存储为 ivar 吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13792963/