惰性实例化不利于iOS [英] Lazy Instantiation Disadvantages iOS

问题描述

因此，似乎懒惰实例化已被广泛使用，每个人都知道懒惰实例化的优点.

So it seems lazy instantiation is widely used and everybody know the advantages of lazy instantiation.

哪个导致了一个问题:我们应该懒惰地实例化每个对象吗?

Which leads to the question: should we lazy instantiate every object?

我对此表示严重怀疑.

问题是，懒惰实例化的缺点是什么?

So the question is, what are the disadvantages of lazy instantiation?

样本取自(Apple Sample LocateMe):

Sample taken from (Apple Sample LocateMe):

- (NSDateFormatter *)dateFormatter {
    if (dateFormatter == nil) {
        dateFormatter = [[NSDateFormatter alloc] init];
        [dateFormatter setDateStyle:NSDateFormatterMediumStyle];
        [dateFormatter setTimeStyle:NSDateFormatterLongStyle];
    }
    return dateFormatter;
}

这将为我们提供仅在需要时初始化该对象的优点.

This will give us the advantage of only initialising this object when it is needed.

顺便说一下，上面的示例来自Apple，看来他们只是懒惰地实例化只读"对象.

By the way, the above sample taken from Apple, it seems like they only lazy instantiate "readonly" objects.

推荐答案

好吧，我想我将以答复的形式改写我的回答(广告，您现在有太多评论了)...

Ok, figured I'll reword my response in the form of an answer (ad you've got too many comments now)...

在您给出的示例中，可以安全地多次使用同一对象实例，因为其内部状态不受影响.也就是说，它正在提供服务，并且不会在两次调用之间保持状态.

In the example you've given, it's safe to use the same object instance multiple times as its internal state is unaffected. That is, it's providing a service and won't keep state between calls.

通常，惰性实例仅与Singleton或通过工厂提供的实例真正相关.例如，像您的示例一样，实例在服务"或应用程序的生存期内(例如资源处理)生存.通常，尽管如此，您通常只需要在需要时创建一个新的对象实例.

As a general rule, lazy instantiation is only really relevant to Singletons or those instances provided through a factory. For instance, like in your example, instances living for the duration of a "service" or application - such as resource handling. Usually though, you often just want to create a new object instance when you need it.

惰性初始化的优点/缺点是:

The advantages/ disadvantages of lazy initialization are:

• 您只需要初始化一个对象一次，并且一个实例即可满足所有服务调用.通话之间不会保持状态.这样做的好处是，加载对象可能很耗时，因此可以避免启动成本，或者在单例情况下避免实例化多个昂贵的对象.这也适用于内存占用量-一个实例，而不是多个实例.
• 如果您懒惰地对一个对象进行延迟，则在运行时会付出一定的代价，因为这实际上已延迟了其构造.因此，在运行时，当用户等待时，您可以创建一个昂贵的对象.不理想，因此应该避免这种情况-如果它又是长期服务对象.
• 在您给出的示例中，还有一个记忆责任的问题.客户端代码显然负责释放此实例.如果这是一个长期服务的对象，那么他们将在哪里做呢?好吧，您可能需要监视NSApp的委托以获取applicationWillTerminate.
• 如果实例保持在实例的方法调用之间设置的状态，则此模式将不起作用.两次调用之间的实例状态可能不一致(可能已更改).

还请注意，这是一个实例方法，用于设置实例var的值(如果为空)...这意味着，在这种情况下，每个封闭的类实例(定义了此方法的类)仍将有一个实例).在这种情况下，您的封闭实例负责清理.确实，我认为这是为了使代码更清晰，而不是内存管理.也许封闭的类是长期存在的，它可以节省重新创建格式化程序的可能性(也许重新创建比重置更昂贵).

Note also that this is an instance method setting the value of an instance var if it's null... This means that, in this case, you will still have one instance per your enclosing class instance (class where this method is defined). In this context, your enclosing instance is responsible for clean up. Really, I think that this is for clarity of code, rather than memory management. Or perhaps the enclosing class is long-lived and it saves re-creating your formatter (perhaps it's more expensive to recreate than reset).

将进行编辑.希望对您有所帮助.

will edit if anything else comes to mind. Hope it helps.

这篇关于惰性实例化不利于iOS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！