Który wzór do pakowania NSUserDefaults?

Question

Moje aplikacje używają [NSUserDefaults standardUserDefaults] jako szybkiej i brudnej bazy danych do przechowywania stanu o użytkowniku i samej aplikacji. Problem z NSUserDefaults polega na tym, że jego elastyczność pozwala na duży bałagan w dół, na przykład, gdy różne pliki ustawiają się i czytają różne klucze w słowniku na swój własny sposób. Nie możesz wymuszać reguł, możesz zepsuć kluczową nazwę itp.

Napisałem prostą, singletonową "menedżersko-stylową" okładkę dla NSUserDefaults, która dba o ustawienie domyślnych wartości, gdy jest używana, ukrywa nazwa kluczy używanych do pobierania wartości i enkapsuluje pewną dodatkową logikę, na przykład kodowanie do NSData, podczas przechowywania i pobierania obiektów ze sklepu.

W tym momencie są to właściwości wspierane przez read/set accessor, ale coś mnie o to niepokoi i zastanawiam się, czy istnieje bardziej elegancki sposób na osiągnięcie tego samego rezultatu. Jest całkiem sporo podstaw, a składnia staje się nieco nieprzyjemna. Aby dać przykład:

.h:

@interface UserDefaultsManager: NSObject 

+ (UserDefaultsManager *)sharedInstance; 

@property (nonatomic, assign) NSInteger somethingImTracking; 

@end 

i .m:

NSString * const kSomethingImTracking= @"SomethingImTracking"; 

@implementation UserDefaultsManager 

[...] 

- (NSInteger)somethingImTracking 
{ 
    return [[[NSUserDefaults standardUserDefaults] objectForKey:kSomethingImTracking] intValue]; 
} 

- (void)setSomethingImTracking:(NSInteger)somethingImTracking 
{ 
    [[NSUserDefaults standardUserDefaults] setInteger:somethingImTracking forKey:kSomethingImTracking]; 
} 

i uzyskać dostęp do:

NSInteger foo = [UserDefaultsManager sharedInstance].somethingImTracking; 

Answer 1

Osobiście używam stałe ciągów znaków do zapamiętywania kluczowe nazwy i po prostu uzyskaj bezpośredni dostęp do obiektu domyślnego użytkownika, ale nie używam wartości domyślnych w dużym stopniu lub w wielu różnych językach osły.

Jednym z ulepszeń, które wprowadziłbym do twojego kodu, jest posiadanie ich jako metod klasowych. Nie ma żadnej korzyści dla singletona (nie utrzymujesz żadnego stanu, to wszystko jest w obiekcie domyślnym), a to wymaga fragmentu brzydkiego powtarzalnego kodu (...sharedInstance) z wzorca użycia.

synchronize nie jest konieczne uwzględnianie przy każdym ustawieniu. Jest potrzebny tylko w przypadku szybkiego dostępu do wartości domyślnych z różnych wątków. System operacyjny również sam je okresowo.