懒惰实例化缺点iOS
所以似乎懒惰的实例化被广泛使用，每个人都知道懒惰实例的优点。
这导致了一个问题：我们应该懒惰实例化每个对象？
我严重怀疑。
所以问题是，懒惰实例有什么缺点？
取自（苹果示例LocateMe）的样本：
- (NSDateFormatter *)dateFormatter { if (dateFormatter == nil) { dateFormatter = [[NSDateFormatter alloc] init]; [dateFormatter setDateStyle:NSDateFormatterMediumStyle]; [dateFormatter setTimeStyle:NSDateFormatterLongStyle]; } return dateFormatter; } 这将给我们的优势，只有在需要的时候初始化这个对象。
顺便说一下，从苹果上面的例子，似乎他们只懒得实例化“只读”的对象。
好的，我认为我会以答案的forms重写我的回答（广告你现在有太多的评论）…
在你给出的例子中，多次使用相同的对象实例是安全的，因为它的内部状态不受影响。 也就是说，它提供的服务并不会保持呼叫之间的状态。
一般来说，懒惰的实例化只与单身人士或通过工厂提供的实例有关。 例如，就像在你的例子中一样，在“服务”或应用程序期间生存的实例 – 比如资源处理。 通常情况下，你经常只是想在你需要的时候创build一个新的对象实例。
延迟初始化的优点/缺点是：
- 你只需要初始化一个对象一次，一个实例就可以满足所有的服务调用。 国家之间不会举行。 这样做的好处是该对象可能会耗费时间来加载，所以您可以避免启动成本，或者在单例环境中避免实例化多个昂贵的对象。 这也适用于内存占用 – 一个实例，而不是很多。
- 尽pipe如此，如果你在一个物体上进行懒惰的工作，那么在运行时就会有成本，因为你实际上已经推迟了它的构build。 所以，在运行时，当用户在等待时，你去创build一个昂贵的对象。 不理想，所以你应该避免这一点 – 如果它是一个长期的服务对象了。
- 在你给出的例子中，还有一个记忆责任的问题。 客户端代码显然负责释放这个实例。 如果这是一个长期的服务对象，他们在哪里做？ 那么，你可能不得不观看NSW的委托applicationWillTerminate。
- 如果一个实例维护一个实例上的方法调用之间的状态，那么这个模式不能工作。 实例的状态可能在调用之间不一致（可能已更改）。
还要注意，这是一个实例方法，如果它是null，则设置实例var的值。这意味着，在这种情况下，对于您的封闭类实例（定义此方法的类），仍然会有一个实例。 在这种情况下，你的封装实例负责清理。 真的，我认为这是为了清晰的代码，而不是内存pipe理。 或者封闭的类可能是长期存在的，它节省了重新创build格式化程序（可能重新创build比重置要更昂贵）。
如果还有其他任何想法会编辑。 希望能帮助到你。