Question

我的团队发现我们在整个代码库中使用了各种NSDateFormatter对象，并开始研究如何避免在一堆独立的地方分配/初始化常见格式化程序的成本/混淆。 / p>

我们的一个想法是在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更便宜？

还有其他方法可以带到这里吗？

我们已经开始运行了，但是在编写“更好”的代码时得到一些反馈总是好的。

Answer 1

通常情况下，你不必担心。 Obj-C会让你摆弄几乎所有东西的多汁内容。即使@private也无法防范-valueForKey:_thatFunPrivateIvar。如果所有其他方法都失败了，您只需调用运行时函数。

但是，此处最简单的解决方法是公开内部使用缓存格式化程序的API，但不提供对其使用的格式化程序的访问权限。然后，您的代码将使用+[Formatter shortTimeStringFromDate:]来执行示例代码现在正在执行的操作。有问题的格式化程序可能会被延迟分配，您可以使用可清除内存，因此可以在内存压力下以LRU方式清除缓存的格式化程序。

共享NSDateFormatter - 最佳实践？

1 个答案: