прочтения ответов навопрос Что касается синглетонов в Objective C, то кажется, что каждое решение имеет некоторый компромисс в отношении потоков в экземпляре метода доступа. то есть

@synchronized(self)
{
    if (sharedInstance == nil)
            sharedInstance = [[MySingleton alloc] init];
}
return sharedInstance;

Это, по сути, однопотоковый доступ к синглтону, и если это то, что часто используется в операции, похоже на то, что может привести к ненужному конфликту потоков.

В чем заключается недостаток простого использования объекта класса в качестве экземпляра синглтона и предоставления функциональности с помощью методов класса, т.е.

@interface MySingleton : NSObject {
}

+ (void)doSomething;
@end

@implementation MySingleton    
+ (void)initialize {
   //do some setup if necessary
}

+ (void)doSomething {
    //do something
}
@end

Таким образом, мы избегаем проверки lock + каждый раз, когда хотим сослаться на одноэлементный объект, и мы также можем избавиться от необходимости хранить его в локальном методе или методе ivar.

Этот подход также позволяет среде выполнения гарантировать, что в любой момент времени в системе существует только один экземпляр (объект Class).

РЕДАКТИРОВАТЬ

Здесь есть нечто большее, чем просто многопоточность, с традиционным синглтоном вы обычно пишете такой код:

MySingleton *instance = [MySingleton getSharedInstance];
NSObject *someResult = [instance getResult];
//or
if (instance.someProperty) {
  //do something
}

Однако, если ваш синглтон является экземпляром класса, вы по существу исключаете необходимость вызова getSharedInstance все время. Рассмотрим этот код:

NSObject *someResult = [MySingleton getResult];
//or
if ([MySingleton someProperty]) {
  //do something
}

Я слышал, что вы должны хранить ваши данные в локальных статических переменных файла или в глобальных переменных (хм). Но на самом деле это не сильно отличается от традиционного синглтона, за исключением того, что вы теряете свойства Objective-C 2.0 (вместо этого вы должны использовать традиционные методы доступа).

Вот один из ключевых компромиссов для меня, который выглядит как победа. В традиционном синглтоне вы переопределяете -copyWithZone, + allocWithZone, -retain, -retainCount, -release и -autorelease, если вы действительно хотите сделать все правильно.

Кажется, это огромная работа, которую нужно выполнять каждый раз, когда вы хотите написать простой объект Singleton (они оказываются довольно полезными). Так почему бы просто не заменить его на это:

@implementation MySingleton
+ (void)initialize {
    //do your setup
}

- (id)init {
    NSAssert(NO, @"You should read the documentation on singletons.");
}
@end

Это намного легче с точки зрения кода, и если ваши потребители не будут хитрыми, они никогда не создадут два экземпляра.

Добраться до сути уже Мой вопрос действительно такой:

Есть ли недостаток в использовании объекта Class в качестве экземпляра вашего синглтона?

Похоже, что вы можете предпринять все те же шаги с точки зрения безопасности потоков, эффективности памяти и т. Д. Без необходимости перезаписывать так много методов и методов доступа или засорять ваш код проверками экземпляров.