CODEWITHSUNDEEP
singleton
Hari c
Hari c

Reputation: 1159

Difference between Singleton class and singleton method?

I have one question.

What is the difference between singleton class and singleton method. I have created shared instance method, if I use alloc method, it will create new instance or not? Thanks in advance

Upvotes: 1

Views: 188

Answers (1)

Rob
Rob

Reputation: 438212

The "singleton pattern" (or a "singleton class" or just "singleton") is simply any class for which you are only allowed a single instance.

A "singleton method" would refer to the method that one writes to access the instance. (Nowadays, in Swift and Objective-C, the public interface would declare a property to access the singleton, not a method, but the idea is the same.)

Conventionally the "singleton pattern" refers to a class that simply would not permit the creation of additional instances. But it should be noted that the term "singleton" is sometimes used more loosely in those cases where there exists a single shared instance, but for which you may actually permit creation of your own instances, too. An example of that would be NSURLSession, whose sharedSession property is referred to as a "singleton" in the Apple documentation, but one is still permitted to create ones' own custom NSURLSession sessions.

Bottom line, whether you design your singleton in such a manner that you can or cannot instantiate additional instances is a question of the design of your class. (Many assiduously insist that this is the very meaning of "singleton". I'm not going to participate in that debate.) In many cases, we explicitly want to want to prevent the accidental creation instances. In other (more rare) cases, though, you may want to permit both a singleton as well as the ability to create additional instances. It's just a question of the intent of the singleton's class.

Note, your question was originally tagged . An Objective-C implementation might look as follows:

NS_ASSUME_NONNULL_BEGIN

@interface Foo : NSObject

@property (class, strong, readonly) Foo *sharedFoo;

- (instancetype)init __attribute__((unavailable("Use +[Foo sharedFoo] instead")));
+ (instancetype)new __attribute__((unavailable("Use +[Foo sharedFoo] instead")));

@end

NS_ASSUME_NONNULL_END

And

@implementation Foo

+ (Foo *)sharedFoo {
    static Foo *sharedFoo = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sharedFoo = [[self alloc] init];
    });
    return sharedFoo;
}

- (id)init {
    if ((self = [super init])) {
        // do additional initialization here
    }
    return self;
}

@end

Note:

  1. Nowadays one would generally define the singleton to be accessed through a @property in the public interface, not as a method. This property would be declared as class and readonly, and you would then manually implement the getter accessor method for that property.

    By defining this public interface to be a property rather than a method, should you ever interface with this object via Swift, you will be accessing it using patterns more common in Swift. You don't have to define it as a property, but you generally would.

  2. Note that I defined this property to be sharedFoo, rather than sharedInstance or sharedManager. By calling it sharedFoo, when you bridge this code with Swift, it will automatically be exposed as shared, the more concise name that Swift, as a matter of convention, uses for its singletons and other shared instances.

  3. In this case I have declared init and new as unavailable. This will prevent developers from accidentally instantiating additional instances. Again, this is a question of the purpose of the singleton.

If you look at singletons (or other shared instances) throughout the Cocoa API, you'll see that Apple has transitioned to this property approach.

Upvotes: 2

Related Questions