Wenn Sie auf iOS 4.0 oder höher abzielen können

Ist es mit GCD der beste Weg, Singleton in Objective-C (thread-sicher) zu erstellen?

+ (instancetype)sharedInstance
{
    static dispatch_once_t once;
    static id sharedInstance;
    dispatch_once(&once, ^{
        sharedInstance = [[self alloc] init];
    });
    return sharedInstance;
}

Dies ist eine absolut akzeptable und threadsichere Methode, um eine Instanz Ihrer Klasse zu erstellen. Es kann technisch gesehen kein "Singleton" sein (da es immer nur eines dieser Objekte geben kann), aber solange Sie nur die [Foo sharedFoo]Methode verwenden, um auf das Objekt zuzugreifen, ist dies gut genug.

Instanztyp

instancetypeist nur eine der vielen Spracherweiterungen Objective-C, mit jeder neuen Version werden weitere hinzugefügt.

Wisse es, liebe es.

Nehmen Sie als Beispiel, wie Sie durch die Beachtung der Details auf niedriger Ebene Einblicke in leistungsstarke neue Möglichkeiten zur Transformation von Objective-C erhalten.

Siehe hier: Instanztyp

+ (instancetype)sharedInstance
{
    static dispatch_once_t once;
    static id sharedInstance;

    dispatch_once(&once, ^
    {
        sharedInstance = [self new];
    });    
    return sharedInstance;
}

+ (Class*)sharedInstance
{
    static dispatch_once_t once;
    static Class *sharedInstance;

    dispatch_once(&once, ^
    {
        sharedInstance = [self new];
    });    
    return sharedInstance;
}

MySingleton.h

@interface MySingleton : NSObject

+(instancetype)sharedInstance;

+(instancetype)alloc __attribute__((unavailable("alloc not available, call sharedInstance instead")));
-(instancetype)init __attribute__((unavailable("init not available, call sharedInstance instead")));
+(instancetype)new __attribute__((unavailable("new not available, call sharedInstance instead")));
-(instancetype)copy __attribute__((unavailable("copy not available, call sharedInstance instead")));

@end

MySingleton.m

@implementation MySingleton

+(instancetype)sharedInstance {
    static dispatch_once_t pred;
    static id shared = nil;
    dispatch_once(&pred, ^{
        shared = [[super alloc] initUniqueInstance];
    });
    return shared;
}

-(instancetype)initUniqueInstance {
    return [super init];
}

@end

Sie können vermeiden, dass die Klasse zugewiesen wird, indem Sie die Zuweisungsmethode überschreiben.

@implementation MyClass

static BOOL useinside = NO;
static id _sharedObject = nil;


+(id) alloc {
    if (!useinside) {
        @throw [NSException exceptionWithName:@"Singleton Vialotaion" reason:@"You are violating the singleton class usage. Please call +sharedInstance method" userInfo:nil];
    }
    else {
        return [super alloc];
    }
}

+(id)sharedInstance
{
    static dispatch_once_t p = 0;
    dispatch_once(&p, ^{
        useinside = YES;
        _sharedObject = [[MyClass alloc] init];
        useinside = NO;
    });   
    // returns the same object each time
    return _sharedObject;
}

Dave hat recht, das ist vollkommen in Ordnung. In den Apple-Dokumenten zum Erstellen eines Singletons finden Sie Tipps zur Implementierung einiger anderer Methoden, um sicherzustellen, dass nur eine erstellt werden kann, wenn Klassen die sharedFoo-Methode NICHT verwenden.

Wenn Sie sicherstellen möchten, dass [[MyClass alloc] init] dasselbe Objekt wie sharedInstance zurückgibt (meiner Meinung nach nicht erforderlich, aber einige Leute möchten es), können Sie dies sehr einfach und sicher mit einem zweiten dispatch_once tun:

- (instancetype)init
{
    static dispatch_once_t once;
    static Class *sharedInstance;

    dispatch_once(&once, ^
    {
        // Your normal init code goes here. 
        sharedInstance = self;
    });

    return sharedInstance;
}

Dadurch kann jede Kombination von [[MyClass alloc] init] und [MyClass sharedInstance] dasselbe Objekt zurückgeben. [MyClass sharedInstance] wäre nur ein bisschen effizienter. So funktioniert es: [MyClass sharedInstance] ruft [[MyClass alloc] init] einmal auf. Andere Codes könnten es auch beliebig oft aufrufen. Der erste Aufrufer von init führt die "normale" Initialisierung durch und speichert das Singleton-Objekt in der init-Methode. Bei späteren Aufrufen von init wird die zurückgegebene Zuordnung vollständig ignoriert und dieselbe sharedInstance zurückgegeben. Das Ergebnis der Zuweisung wird freigegeben.

Die + sharedInstance-Methode funktioniert wie immer. Wenn es nicht der erste Aufrufer ist, der [[MyClass alloc] init] aufruft, ist das Ergebnis von init nicht das Ergebnis des Alloc-Aufrufs, aber das ist in Ordnung.

Sie fragen, ob dies der "beste Weg ist, um Singleton zu erstellen".

Ein paar Gedanken:

1. Erstens, ja, dies ist eine thread-sichere Lösung. Dieses dispatch_onceMuster ist die moderne, thread-sichere Methode zum Generieren von Singletons in Objective-C. Keine Sorge da.

2. Sie haben jedoch gefragt, ob dies der "beste" Weg ist, dies zu tun. Man sollte jedoch anerkennen, dass das instancetypeund[[self alloc] init] in Verbindung mit Singletons möglicherweise irreführend ist.

   Der Vorteil von instancetypeist, dass es eine eindeutige Methode ist, zu erklären, dass die Klasse in Unterklassen unterteilt werden kann, ohne auf eine Art von Klasse zurückzugreifenid , wie wir es früher getan haben.

   Aber das staticin dieser Methode stellt Unterklassenherausforderungen. Was wäre, wenn ImageCacheund BlobCacheSingletons beide Unterklassen einer CacheOberklasse wären, ohne ihre eigene sharedCacheMethode zu implementieren ?

   ImageCache *imageCache = [ImageCache sharedCache];  // fine
   BlobCache *blobCache = [BlobCache sharedCache];     // error; this will return the aforementioned ImageCache!!!

   Damit dies funktioniert, müssen Sie sicherstellen, dass Unterklassen ihre eigenen implementieren sharedInstance Methode (oder wie auch immer Sie sie für Ihre bestimmte Klasse nennen) .

   Unterm Strich sharedInstance sieht Ihr Original so aus, als würde es Unterklassen unterstützen, aber nicht. Wenn Sie Unterklassen unterstützen möchten, fügen Sie zumindest eine Dokumentation hinzu, die zukünftige Entwickler warnt, dass sie diese Methode überschreiben müssen.

3. Für eine optimale Interoperabilität mit Swift möchten Sie dies wahrscheinlich als eine Eigenschaft definieren, nicht als eine Klassenmethode, z. B.:

   @interface Foo : NSObject
   @property (class, readonly, strong) Foo *sharedFoo;
   @end

   Dann können Sie einen Getter für diese Eigenschaft schreiben (die Implementierung würde das von dispatch_onceIhnen vorgeschlagene Muster verwenden):

   + (Foo *)sharedFoo { ... }

   Dies hat den Vorteil, dass ein Swift-Benutzer, wenn er es verwendet, Folgendes tun würde:

   let foo = Foo.shared

   Beachten Sie, dass dies nicht der Fall ist (), da wir es als Eigenschaft implementiert haben. Ab Swift 3 wird im Allgemeinen auf Singletons zugegriffen. Die Definition als Eigenschaft erleichtert die Interoperabilität.

   Abgesehen davon, wenn Sie sich ansehen, wie Apple ihre Singletons definiert, ist dies das Muster, das sie übernommen haben, z. B. ist ihr NSURLSessionSingleton wie folgt definiert:

   @property (class, readonly, strong) NSURLSession *sharedSession;

4. Eine weitere, sehr geringfügige Überlegung zur Swift-Interoperabilität war der Name des Singletons. Es ist am besten, wenn Sie den Namen des Typs einfügen und nicht sharedInstance. Wenn die Klasse beispielsweise war Foo, können Sie die Singleton-Eigenschaft als definieren sharedFoo. Oder wenn die Klasse war DatabaseManager, können Sie die Eigenschaft aufrufen sharedManager. Dann könnten Swift-Benutzer Folgendes tun:

   let foo = Foo.shared
   let manager = DatabaseManager.shared

   Wenn Sie wirklich verwenden möchten sharedInstance, können Sie den Swift-Namen jederzeit deklarieren , wenn Sie möchten:

   @property (class, readonly, strong) Foo* sharedInstance NS_SWIFT_NAME(shared);

   Wenn Sie Objective-C-Code schreiben, sollten wir nicht zulassen, dass die Swift-Interoperabilität andere Entwurfsüberlegungen überwiegt. Wenn wir jedoch Code schreiben können, der beide Sprachen ordnungsgemäß unterstützt, ist dies vorzuziehen.

5. Ich stimme anderen zu, die darauf hinweisen, dass, wenn Sie möchten, dass dies ein echter Singleton ist, bei dem Entwickler ihre eigenen Instanzen nicht (versehentlich) instanziieren können / sollten, das unavailableQualifikationsmerkmal aktiviert ist initund newumsichtig ist.

So erstellen Sie einen thread-sicheren Singleton:

@interface SomeManager : NSObject
+ (id)sharedManager;
@end

/* thread safe */
@implementation SomeManager

static id sharedManager = nil;

+ (void)initialize {
    if (self == [SomeManager class]) {
        sharedManager = [[self alloc] init];
    }
}

+ (id)sharedManager {
    return sharedManager;
}
@end

und dieser Blog erklärt Singleton sehr gut Singletons in Objc / Kakao

//Create Singleton  
  +( instancetype )defaultDBManager
    {

        static dispatch_once_t onceToken = 0;
        __strong static id _sharedObject = nil;

        dispatch_once(&onceToken, ^{
            _sharedObject = [[self alloc] init];
        });

        return _sharedObject;
    }


//In it method
-(instancetype)init
{
    self = [super init];
  if(self)
     {
   //Do your custom initialization
     }
     return self;
}

@interface className : NSObject{
+(className*)SingleTonShare;
}

@implementation className

+(className*)SingleTonShare{

static className* sharedObj = nil;
static dispatch_once_t once = 0;
dispatch_once(&once, ^{

if (sharedObj == nil){
    sharedObj = [[className alloc] init];
}
  });
     return sharedObj;
}