Shared NSDateFormatter - Best Practices?

Моя команда обнаружила, что мы использовали различные объекты NSDateFormatter во всей нашей кодовой базе, и начали искать способы избежать затрат / путаницы при выделении / инициализации общих средств форматирования в кучу разных мест.

У нас была одна идея - создать категорию в классе NSDateFormatter , которая предоставила бы ссылка на статический экземпляр обычно настраиваемого средства форматирования. Например, мы использовали "кратковременный" форматер даты в нескольких местах и ​​хотели добавить следующий метод класса:

@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

Одна из проблем, с которыми я столкнулся с этим подходом, заключается в том, что в настоящее время мы не "защищаем" NSDateFormatter не подлежит изменению. Поскольку средство форматирования по существу является "общим" для всего нашего приложения, это может потенциально вызвать проблемы, если другой объект должен изменить конфигурацию средства форматирования (например, стиль времени / даты).

Поскольку мы используем это внутри компании, я не слишком обеспокоен риском того, что наша команда неправильно воспользуется этой функцией (т.е. это небольшая команда, и это четко прокомментировано).

Однако меня интересуют передовые практики.

Есть ли способ вернуть неизменяемую ссылку на средство форматирования даты? Если я верну копию средства форматирования, будет ли это дешевле, чем выполнение alloc / inits, которые мы делаем сейчас?

Есть ли какой-то другой подход здесь?

Мы будем работать с это, но всегда полезно получить обратную связь при написании «лучшего» кода.