Corriger le Pattern Singleton Objective-C (iOS)?

J'ai trouvé quelques informations sur le net pour créer une classe singleton à l'aide de PGCD. C'est cool parce que c'est thread-safe avec de très faible hauteur. Malheureusement je ne pouvais pas trouver de solutions complètes, mais seulement des extraits de l'sharedInstance méthode. J'ai donc fait ma propre classe à l'aide de la méthode essai-erreur - et et voila - ce qui suit est sorti:

@implementation MySingleton

//MARK: -
//MARK: Singleton Pattern using GCD

+ (id)allocWithZone:(NSZone *)zone { return [[self sharedInstance] retain]; }
- (id)copyWithZone:(NSZone *)zone { return self; }
- (id)autorelease { return self; }
- (oneway void)release { /* Singletons can't be released */ }
- (void)dealloc { [super dealloc]; /* should never be called */ }
- (id)retain { return self; }
- (NSUInteger)retainCount { return NSUIntegerMax; /* That's soooo non-zero */ }

+ (MySingleton *)sharedInstance
{
    static MySingleton * instance = nil;

    static dispatch_once_t predicate;   
    dispatch_once(&predicate, ^{
        //--- call to super avoids a deadlock with the above allocWithZone
        instance = [[super allocWithZone:nil] init];
    });

    return instance;
}

//MARK: -
//MARK: Initialization

- (id)init
{
    self = [super init];
    if (self) 
    {
        //Initialization code here.
    }
    return self;
}

@end

N'hésitez pas à commenter et me dire si j'ai raté quelque chose ou de faire quelque chose de complètement faux 😉

Cheers
Stefan

Je serais tenté d'ajouter un -(void)dealloc qui lève une exception, de cette façon, vous devriez être en mesure de traquer la délinquance acteur si quelqu'un est d'obtenir une instance du singleton et puis en le relâchant. En plus d'être un abus du motif, je veux vous laisser avec un bancales pointeur.
meta question: est-ce que ce sera à [codereview.stackexchange.com/]?
apple conseille fortement de ne pas créer des singletons primordial de conserver/release! cela permettra de briser les applications de la transition à l'ARC
Double/étroitement liés: Quel est votre Objectif-C singleton ressembler?

InformationsquelleAutor blackjacx | 2011-09-29

82

Faire simple:
```
+(instancetype)sharedInstance
{
    static dispatch_once_t pred;
    static id sharedInstance = nil;
    dispatch_once(&pred, ^{
        sharedInstance = [[self alloc] init];
    });
    return sharedInstance;
}

- (void)dealloc
{
    //implement -dealloc & remove abort() when refactoring for
    //non-singleton use.
    abort();
}
```
Qui est-il. Primordial retain, release, retainCount et le reste est juste la clandestinité de bugs et l'ajout d'un tas de lignes de code inutile. Chaque ligne de code est un bug en attente de se produire. En réalité, si vous en êtes la cause dealloc d'être appelé sur votre instance partagée, vous avez un très sérieux bogue dans votre application. Ce bug devrait être corrigé, et non pas caché.

Cette approche se prête également à la refactorisation à l'appui de la non-singleton utilisation de modes. À peu près chaque singleton qui survit au-delà de quelques releases sera finalement refait dans une situation de non-singleton forme. Certains (comme NSFileManager) continuer à soutenir un singleton mode tout en soutenant l'arbitraire de l'instanciation.

Remarque que ci-dessus aussi "fonctionne" dans l'ARC.
- merci pour cette...juste une question à propos du statiquement objet créé. Ne devriez pas vous libérer cet objet je dealloc? je suis toujours confus au sujet de la propriété des objets statiques. Donc, vous ne devriez pas avoir quelque chose comme [[Maclasse sharedInstance] release]; dans le dealloc?
- Les Singletons exister à partir du moment où ils sont demandés jusqu'à ce que l'application se termine. Ils ne sont pas libérées et re-instancié. Comme il n'y a aucune raison pour désallouer rien sur l'arrêt de l'application, il n'y a pas de raison de release le singleton. Parce qu'il est peu probable que le singleton de destruction n'a jamais été testé, la mise en œuvre de la dealloc comme le montre est purement défensive mesure de rappeler à l'avenir vous avez passé, vous n'avez pas pensé à propos de la gestion de la mémoire pour cette classe.
- Merci pour la clarification
- un petit plus, l' (id) doit être (instanceType)..pour plus de détails lire cette question
- Bonjour, pouvez-vous faire à l'aide d'swift langue? Merci.
- J'ai ajouté un autre répondre pour la création d'un singleton avec Swift.
- pourquoi utilisez-vous [[self class] alloc] au lieu de [self alloc] dans + méthode?
InformationsquelleAutor bbum
19
```
//See Mike Ash "Care and Feeding of Singletons"
//See Cocoa Samurai "Singletons: You're doing them wrong"
+(MySingleton *)singleton {
    static dispatch_once_t pred;
    static MySingleton *shared = nil;
    dispatch_once(&pred, ^{
        shared = [[MySingleton alloc] init];
        shared.someIvar = @"blah";
    });
    return shared;
}
```
Être conscient que dispatch_once n'est pas réentrant, afin de l'appelant lui-même de l'intérieur de la dispatch_once bloc de blocage du programme.

N'essayez pas de code défensivement contre vous-même. Si vous n'êtes pas le codage d'un cadre, de traiter votre classe normale puis coller le singleton idiome ci-dessus. Pensez à le singleton idiome comme une méthode de convenance, non pas comme une caractéristique de votre classe. Vous voulez traiter votre classe comme une classe normale au cours de tests unitaires, donc c'est OK pour laisser accessible constructeur.

Ne vous embêtez pas à l'aide de allocWithZone:
- Il ignore son argument et se comporte exactement comme alloc. Les zones mémoire sont plus utilisés en Objective-C, afin de allocWithZone: ne sont conservés que pour la compatibilité avec l'ancien code.
- Il ne fonctionne pas. Vous ne pouvez pas appliquer singleton comportement en Objective-C, parce que plus de cas peut toujours être créé à l'aide de NSAllocateObject() et class_createInstance().
Un singleton, factory méthode renvoie toujours l'un de ces trois types:
- id pour indiquer le type de retour n'est pas entièrement connue (cas où vous êtes la construction d'une classe de cluster).
- instancetype pour indiquer que le type retourné est une instance de la classe englobante.
- Le nom de la classe elle-même (MySingleton dans l'exemple) pour garder les choses simples.
Puisque vous tagged cet iOS, une alternative à un singleton est une économie de la ivar pour le délégué d'application, puis à l'aide d'une commodité de macro que vous pouvez redéfinir si vous changez d'avis:
```
#define coreDataManager() \
        ((AppDelegate*)[[UIApplication sharedApplication] delegate]).coreDataManager
```
InformationsquelleAutor Jano

Si vous voulez de l'unité de test de votre singleton, vous devez également faire en sorte que vous pouvez le remplacer par un simulacre de singleton et/ou de le remettre à la normale:

@implementation ArticleManager

static ArticleManager *_sharedInstance = nil;
static dispatch_once_t once_token = 0;

+(ArticleManager *)sharedInstance {
    dispatch_once(&once_token, ^{
        if (_sharedInstance == nil) {
            _sharedInstance = [[ArticleManager alloc] init];
        }
    });
    return _sharedInstance;
}

+(void)setSharedInstance:(ArticleManager *)instance {
    once_token = 0; //resets the once_token so dispatch_once will run again
    _sharedInstance = instance;
}

@end

Je marche à travers chaque ligne de cet exemple de code dans un post de blog ici: twobitlabs.com/2013/01/...

InformationsquelleAutor ToddH

Vous devez vous connecter pour publier un commentaire.