The only thing I'd watch out for here is that while the property may seem to be read-only, a List<> is a mutable object, and thus whomever gets the reference can alter it. They can't null out the private member, but they can make the List<> empty. I'd return an IEnumerable<> or something instead if you can get away with it. But that's not your direct question. What Oded said seems OK to me.
–
Kevin AndersonApr 5 '10 at 15:55

3

@Kevin: ReadOnlyCollection<Note> is a good choice here as well (arguably better since it offers indexing and the entire array is available).
–
Sam HarwellApr 5 '10 at 16:03

In additional to the original post, in terms of 'separation of concerns' it would be nice to be able to have a class that just returns the data as normal, and then a child class that deals with caching the data. Other than doing it manually, there doesn't seem to be a pretty way of achieving this. Anybody?
–
MarcJan 31 '14 at 8:33

Sorry I messed up the second ??... I corrected it to =. This version will only do the secondary assignment if the value is null. Your version will always reassign the value.
–
Matthew WhitedApr 5 '10 at 16:06

@Matthew that is exactly how I handle any lazy properties as of current day.
–
Chris MarisicApr 5 '10 at 16:12

Looks really cool! Will definitely be using this syntax for <=3.5.Net
–
PeterdkApr 6 '10 at 1:12

Looks interesting, too bad you still need a backing variable. The amount of code is even more spread throughout the class, and it's not really less code to write, so no real benefits I would say. There should be a Lazy Property construction way, just like {get; private set;} but then with a reference to the calculation method that needs to be called.
–
PeterdkApr 6 '10 at 1:15

Peterdk: THat's basically what Lazy<T> gives you.. it's tough to do "lazy construction" via a func<T> without having a separate way to define the construction function. It's quite a bit simpler without that (since you can just use "private Lazy<List<Note>> note = new Lazy<List<Note>>();" (no constructor issues)... This, however, does have the MAJOR advantage of being completely thread safe, where your original is not...
–
Reed CopseyApr 6 '10 at 1:27

Reed: Ok, nice to know. Will look a bit more into the Lazy thing. Can't find out yet if it's supported on WP7, for now I'll use the null-coalescing operating suggested by frou. This is however definitely the way to go in future .Net versions.
–
PeterdkApr 6 '10 at 1:35

If the value is non-trivial to compute, I generally prefer using a method (GetNotes()). There's nothing stopping you from caching the value with a method, plus you can add the [Pure] attribute (.NET 4) if applicable to indicate the method does not alter the state of the object.

If you do decide to stay with the following, I recommend:

Whenever you have a lazily-evaluated property, you should add the following attribute to ensure that running in the debugger behaves the same as running outside of it:

Yes it is possible. The question is, how much you are winning by doing it - you still need the initialization code somewhere, so at most you will be saving the conditional expression.

A while ago I implemented a class to handle this. You can find the code posted in this question, where I ask whether it's a good idea. There are some interesting opinions in the answers, be sure to read them all before deciding to use it.