Shared NSDateFormatter - najlepsze praktyki?

Question

Mój zespół odkrył, że korzystaliśmy z różnych obiektów NSDateFormatter w całej naszej bazie kodu i zaczęliśmy się zastanawiać, w jaki sposób moglibyśmy uniknąć kosztu/zamieszania związanego z przydzielaniem/inicjowaniem popularnych formaterów w kilku osobnych miejscach.

Jednym z pomysłów było stworzenie kategorii na klasie NSDateFormatter, która zapewniałaby odniesienie do statycznej instancji powszechnie skonfigurowanego formatyzatora. Na przykład, używaliśmy „krótki czas” Date formatowania w kilku miejscach, i szukali, aby dodać następujące metody klasy:

@implementation NSDateFormatter (NSDateFormatter_PDDateFormatters) 

static NSDateFormatter * shortTimeFormatter = nil; 

+ (NSDateFormatter *) PDSharedShortTimeFormatter { 

    @synchronized([NSDateFormatter class]){ 

     if(shortTimeFormatter == nil){ 

      // Create new formatter for SHORT times (e.g. 12:00 pm) 

      shortTimeFormatter = [[NSDateFormatter alloc] init]; 
      [shortTimeFormatter setDateStyle: NSDateFormatterNoStyle]; 
      [shortTimeFormatter setTimeStyle:NSDateFormatterShortStyle]; 
     } 

     return shortTimeFormatter; 

    } 

    return nil; 
} 

@end 

Jednym z problemów mam z tego podejścia jest to, że nie są w tej chwili " ochrona "NSDateFormatter przed zmianą. Ponieważ formater jest zasadniczo "udostępniany" w całej naszej aplikacji, może to potencjalnie powodować problemy, jeśli innym obiektem była zmiana konfiguracji formatyzatora (np. Styl czasu/daty).

Ponieważ używamy tego wewnętrznie, nie jestem zbytnio zaniepokojony ryzykiem, że nasz zespół nadużywa tej funkcji (tj. Jest to mały zespół i wyraźnie komentowany).

Jednak zastanawiałem się nad najlepszymi praktykami.

Czy istnieje sposób na zwrócenie niezmiennego odniesienia do formatyzatora daty? Jeśli zwrócę kopię formatyzatora, czy jest to mniej kosztowne niż wykonanie przydziału/inicjałów, które teraz wykonujemy?

Czy jest tu inne podejście?

Będziemy z tym pracować, ale zawsze dobrze jest uzyskać informacje zwrotne na temat pisania "lepszego" kodu.

Answer 1

Zwykle nie martwisz się tym. Obj-C pozwoli ci bawić się soczystymi wnętrzami niemal wszystkiego. Nawet @private nie chroni przed -valueForKey:_thatFunPrivateIvar. A jeśli wszystko inne zawiedzie, możesz po prostu wywołać funkcje uruchomieniowe.

Jednak najprostszym rozwiązaniem jest ujawnienie interfejsu API, który wewnętrznie używa formatów buforowanych, ale nie zapewnia to dostępu do formatów, z których korzysta. Twój kod będzie wtedy używał +[Formatter shortTimeStringFromDate:] do robienia tego, co teraz robi Twój przykładowy kod. Formater, o którym mowa, mógł być leniwie przydzielony i można by było używać pamięci możliwej do usunięcia, dzięki czemu buforowane formatery mogły być usuwane w trybie LRU pod presją pamięci.