Good or bad practice? Initializing objects in getter

I have a strange habit it seems... according to my co-worker at least. We've been working on a small project together. The way I wrote the classes is (simplified example):

[Serializable()]
public class Foo
{
    public Foo()
    { }

    private Bar _bar;

    public Bar Bar
    {
        get
        {
            if (_bar == null)
                _bar = new Bar();

            return _bar;
        }
        set { _bar = value; }
    }
}

So, basically, I only initialize any field when a getter is called and the field is still null. I figured this would reduce overload by not initializing any properties that aren't used anywhere.

ETA: The reason I did this is that my class has several properties that return an instance of another class, which in turn also have properties with yet more classes, and so on. Calling the constructor for the top class would subsequently call all constructors for all these classes, when they are not always all needed.

Are there any objections against this practice, other than personal preference?

UPDATE: I have considered the many differing opinions in regards to this question and I will stand by my accepted answer. However, I have now come to a much better understanding of the concept and I'm able to decide when to use it and when not.

Cons:

Pros:

Most of the cons are not applicable to my current library, however I would have to test to see if the "micro-optimizations" are actually optimizing anything at all.

LAST UPDATE:

Okay, I changed my answer. My original question was whether or not this is a good habit. And I'm now convinced that it's not. Maybe I will still use it in some parts of my current code, but not unconditionally and definitely not all the time. So I'm going to lose my habit and think about it before using it. Thanks everyone!

What you have here is a - naive - implementation of "lazy initialization".

Short answer:

Using lazy initialization unconditionally is not a good idea. It has its places but one has to take into consideration the impacts this solution has.

Background and explanation:

Concrete implementation:
Let's first look at your concrete sample and why I consider its implementation naive:

foo.Bar = null;
Assert.Null(foo.Bar); // This will fail

In general:
It's now time to look at lazy initialization in general:
Lazy initialization is usually used to delay the construction of objects that take a long time to be constructed or that take a lot of memory once fully constructed.
That is a very valid reason for using lazy initialization.

However, such properties normally don't have setters, which gets rid of the first issue pointed out above.
Furthermore, a thread-safe implementation would be used - like Lazy<T> - to avoid the second issue.

Even when considering these two points in the implementation of a lazy property, the following points are general problems of this pattern:

The conclusion of these points is the following:
For each single property that is implemented lazily, you should have considered these points.
That means, that it is a per-case decision and can't be taken as a general best practice.

This pattern has its place, but it is not a general best practice when implementing classes. It should not be used unconditionally , because of the reasons stated above.

In this section I want to discuss some of the points others have brought forward as arguments for using lazy initialization unconditionally:

It is a good design choice. Strongly recommended for library code or core classes.

It is called by some "lazy initialization" or "delayed initialization" and it is generally considered by all to be a good design choice.

First, if you initialize in the declaration of class level variables or constructor, then when your object is constructed, you have the overhead of creating a resource that may never be used.

Second, the resource only gets created if needed.

Third, you avoid garbage collecting an object that was not used.

Lastly, it is easier to handle initialization exceptions that may occur in the property then exceptions that occur during initialization of class level variables or the constructor.

There are exceptions to this rule.

Regarding the performance argument of the additional check for initialization in the "get" property, it is insignificant. Initializing and disposing an object is a more significant performance hit than a simple null pointer check with a jump.

Design Guidelines for Developing Class Libraries at http://msdn.microsoft.com/en-US/library/vstudio/ms229042.aspx

Regarding Lazy<T>

The generic Lazy<T> class was created exactly for what the poster wants, see Lazy Initialization at http://msdn.microsoft.com/en-us/library/dd997286(v=vs.100).aspx. If you have older versions of .NET, you have to use the code pattern illustrated in the question. This code pattern has become so common that Microsoft saw fit to include a class in the latest .NET libraries to make it easier to implement the pattern. In addition, if your implementation needs thread safety, then you have to add it.

Primitive Data Types and Simple Classes

Obvioulsy, you are not going to use lazy-initialization for primitive data type or simple class use like List<string> .

Before Commenting about Lazy

Lazy<T> was introduced in .NET 4.0, so please don't add yet another comment regarding this class.

Before Commenting about Micro-Optimizations

When you are building libraries, you must consider all optimizations. For instance, in the .NET classes you will see bit arrays used for Boolean class variables throughout the code to reduce memory consumption and memory fragmentation, just to name two "micro-optimizations".

Regarding User-Interfaces

You are not going to use lazy initialization for classes that are directly used by the user-interface. Last week I spent the better part of a day removing lazy loading of eight collections used in a view-model for combo-boxes. I have a LookupManager that handles lazy loading and caching of collections needed by any user-interface element.

"Setters"

I have never used a set-property ("setters") for any lazy loaded property. Therefore, you would never allow foo.Bar = null; . If you need to set Bar then I would create a method called SetBar(Bar value) and not use lazy-initialization

Collections

Class collection properties are always initialized when declared because they should never be null.

Complex Classes

Let me repeat this differently, you use lazy-initialization for complex classes. Which are usually, poorly designed classes.

Lastly

I never said to do this for all classes or in all cases. It is a bad habit.

Do you consider implementing such pattern using Lazy<T> ?

In addition to easy creation of lazy-loaded objects, you get thread safety while the object is initialized:

As others said, you lazily-load objects if they're really resource-heavy or it takes some time to load them during object construction-time.

上一篇: WPF图像资源

下一篇: 好的或不好的做法？ 在getter中初始化对象