单例实例与类方法 [英] Singleton Instance vs Class Methods

查看:100
本文介绍了单例实例与类方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

虽然最近在使用Objective-C和其中编写的各种图书馆时,我注意到两个非常流行的单例模式。一个版本获取单例实例并调用其实例方法,其他版本仅暴露类方法,从不给您一个实例。所有这些都是为了提取对单个资源的访问(StoreKit,CoreData,Parse API等)。例如,这是MKStoreKit中使用的前一种方法:

While recently working with Objective-C and various libraries written in it, I've noticed two really popular singleton patterns. One version fetches the singleton instance and calls its instance methods and other version only exposes class methods and never gives you an instance to work with. All have the purpose of abstracting access to a single resource (StoreKit, CoreData, Parse API etc.). For example, here's the former approach used in MKStoreKit:

// initialize singleton during app boot
[MKStoreManager sharedManager]

// sometime later in the app
[[MKStoreManager sharedManager] buyFeature:kFeatureAId 
                                onComplete:^(NSString* purchasedFeature)
 {
     NSLog(@"Purchased: %@", purchasedFeature);
 }
                               onCancelled:^
 {
     NSLog(@"User Cancelled Transaction");
 }];

或NSUserDefaults,UIApplication等。另一种方法可以在MagicalRecord或Parse API中看到:

or alternatively NSUserDefaults, UIApplication etc.. The other approach can be seen in MagicalRecord or here with Parse API:

// configure API credentials sometime during app boot
[Parse setApplicationId:@"123456"
              clientKey:@"123456"];

// sometime later
PFObject *testObject = [PFObject objectWithClassName:@"TestObject"];
[testObject setObject:@"bar" forKey:@"foo"];
[testObject save];

这两种方法有哪些优点和缺点,其中一个从根本上比另一种更好?

What are some pros and cons of the two approaches and is one of them fundamentally better than the other?

无需检索共享实例就可以节省一些屏幕尺寸(性能差异可能无关紧要),但是我以其他方式拧紧了自己,例如可测试性 -

Not having to retrieve the shared instance saves some screen estate (the performance difference is likely irrelevant), but am I screwing myself in some other way, for example, testability-wise?

谢谢!

推荐答案

有两种不同的方法实现基于类方法的方法:

There are two different ways to implement the approach based on class methods:


  • 使用隐藏自己的类创建一个单例实例,并将其隐藏在包装器类方法之后的方法相同的签名,或

  • 使所有的工作的类方法

第一个实现是,您可以使用单身人士做的一切,您可以使用隐藏的单身人士:

The implications of the first implementation are that everything you can do with a singleton, you can do with the hidden singleton:


  • 使用子类成为可能性

  • 在运行中切换实例很容易

  • 状态生活在实例变量中

  • 初始化熟悉的pa ttern

如果你去一个不使用单例的实现,你将依靠静态变量来保持你的当前状态。这是一个合法的选择,但初始化模式变得不同(甚至可能使用 dispatch_once ),您不能在中间切换实现,而不依赖于一些丑陋的如果条件,并且使用子类变得更棘手。

If you go for an implementation that does not use a singleton, you would be relying on static variables to keep your current state. That is a legitimate choice, but the initialization pattern becomes different (perhaps even using a dispatch_once), you cannot switch the implementation in the middle without relying on some ugly if conditions, and using a subclass becomes a lot more tricky.

测试第一个实现比测试第二个实现要容易一些,因为您可以单独提供单例来进行测试,也许通过后门;使用基于静态的实现,不能采用此路由。

Testing the first implementation is somewhat easier than testing the second one, because you can provide a separate implementation of the singleton for testing, perhaps through the back door; with a static-based implementation, this route cannot be taken.

总而言之,我将使用基于单例的解决方案,单选可选隐藏在外观后面这提供了获取单例的方法。我不会使用所有状态必须放在静态变量中的实现。

To summarize, I would use a singleton-based solution, with the singleton optionally hidden behind a "facade" that provides access to singleton's methods. I would not use an implementation where all state must be placed in static variables.

这篇关于单例实例与类方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆