Элегантная и «правильная» многоточечная реализация в Objective C?

Question

Вы бы назвали эту реализацию мультитона в объективе-c 'изящным'? Я программно «запретил» использование alloc и allocWithZone:, потому что решение о распределении или не распределении памяти должно выполняться на основе ключа.

Я точно знаю, что мне нужно работать только с двумя экземплярами, поэтому я использую «switch-case» вместо карты.

#import "Multiton.h" 

static Multiton *firstInstance = nil; 
static Multiton *secondInstance = nil; 

@implementation Multiton 

+ (Multiton *) sharedInstanceForDirection:(enum KeyName)direction { 

    return [[self allocWithKey:direction] init]; 
} 

+ (id) allocWithKey:(enum KeyName)key { 

    return [self allocWithZone:nil andKey:key]; 
} 

+ (id) allocWithZone:(NSZone *)zone andKey:(enum KeyName)key { 

    Multiton **sharedInstance; 

    @synchronized(self) { 

     switch (key) { 
      case KEY_1: 
       sharedInstance = &firstInstance; 
       break; 
      case KEY_2: 
       sharedInstance = &secondInstance; 
       break; 
      default: 
       [NSException raise:NSInvalidArgumentException format:@"Invalid key"]; 
       break; 
     } 
     if (*sharedInstance == nil) 
      *sharedInstance = [super allocWithZone:zone]; 
    } 

    return *sharedInstance; 
} 

+ (id) allocWithZone:(NSZone *)zone { 

    //Do not allow use of alloc and allocWithZone 
    [NSException raise:NSObjectInaccessibleException format:@"Use allocWithZone:andKey: or allocWithKey:"]; 
    return nil; 
} 

- (id) copyWithZone:(NSZone *)zone { 

    return self; 
} 

- (id) retain { 

    return self; 
} 

- (unsigned) retainCount { 

    return NSUIntegerMax; 
} 

- (void) release { 

    return; 
} 

- (id) autorelease { 

    return self; 
} 

- (id) init { 
    [super init]; 
    return self; 
} 

@end 

PS: Я не пробовал, если это работает еще, но его компиляция чисто :)

Answer 1

Я нахожу одиночные игры плохой идеей, и это выглядит примерно в четыре раза ужасно. Код довольно сложный, вы можете быть уверены, что потратите несколько часов на то, чтобы преследовать тонкие ошибки, и вы, вероятно, никогда не будете чувствовать себя комфортно. Это не хорошо. Вы должны отбросить эту мерзость и связать свои объекты каким-то другим способом, который не требует большого внимания.

Если вам нравятся узоры, вы можете использовать что-то похожее на шаблон Factory для проводов ваших объектов. Фабрика позаботится о создании этих двух экземпляров и передает их там, где это необходимо. И завод будет намного более простым, чем многотонные:

@interface Factory : NSObject { 
    Foo *foo1, *foo2; 
} 
@end 

@implementation Factory 

- (id) init { 
    [super init]; 
    foo1 = [[Foo alloc] init]; 
    foo2 = [[Foo alloc] init]; 
    return self; 
} 

Конечно, вы не должны создавать оба экземпляра сразу. Вы можете делать все, что вам нравится - кеш, ленивый груз, что угодно. Дело в том, что управление жизненным циклом Foo до Factory, отдельно от кода Foo. Тогда это становится намного легче. ¶ Все остальные объекты, которые нуждаются в Foo будут созданы и подключены через Factory и получите их Foo через сеттер:

@implementation Factory 

- (id) wireSomeClass { 
    id instance = [[SomeClass alloc] init]; 
    [instance setFoo:foo1]; 
    [instance setAnotherDependency:bar]; 
    return [instance autorelease]; 
} 

Это все гораздо проще, то код из вашего вопроса.

Answer 2

Точки заказа: Как вы знаете, что вы будете только когда-либо иметь два экземпляра, или нужно иметь два экземпляра? (Или хотите иметь два экземпляра?) Что, собственно, есть пункт наличия «мультитона»? (И это даже слово?)

Answer 3

Не отменяйте выделение. Проблема с переопределением alloc для возврата ранее выделенного экземпляра класса, как и вы, заключается в том, что когда + sharedInstance вызывает [[Multiton alloc] init] ... + alloc вернет старый экземпляр, тогда -init будет повторно, инициализируйте его! Лучшей практикой является переопределить -init, выполнить поиск кеша и вызвать [self release], прежде чем вы вернете кешированный экземпляр.

Если вы действительно обеспокоены стоимость этого дополнительного + Alloc (это не так много), вы также сделать ваш поиск тайника в + sharedInstance и убедитесь, что все ваши клиенты получить доступ к экземпляру через + sharedInstance к избегайте дополнительного выделения.