Home/ Questions/Q 141657
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T07:48:42+00:00

I have a class (Foo) which lazy loads a property named (Bar). What is

  • 0

I have a class (Foo) which lazy loads a property named (Bar). What is your preferred way to protect against mistaken use (due to intellisense or inexperienced staff) of the uninitialized backing field?

I can think of 3 options: 

  class Foo {     // option 1 - Easy to use this.bar by mistake.      string bar;     string Bar {         get {             // logic to lazy load bar               return bar;          }     }      // option 2 - Harder to use this._bar by mistake. It is more obscure.     string _bar2;     string Bar2 {         get {             // logic to lazy load bar2               return _bar2;         }     }      //option 3 - Very hard to use the backing field by mistake.      class BackingFields {         public string bar;      }      BackingFields fields = new BackingFields();      string Bar3 {         get {             // logic to lazy load bar               return fields.bar;         }     }  }

Keep in mind, the only place I want people mucking around with the backing field bar is in setter and getter of the property. Everywhere else in the class they should always use this.Bar

Update

I am currently using the following Lazy implementation (not for all properties with backing fields, but for select ones that require lazy loading, synchronization and notification). It could be extended to support futures as well (force evaluation in a separate thread in a later time)

Note My implementation locks on read, cause it supports an external set.

Also, I would like to mention that I think this is a language limitation which can be overcome in Ruby for example.

You can implement lazy in this way.

x = lazy do     puts '<<< Evaluating lazy value >>>'     'lazy value' end  puts x # <<< Evaluating lazy value >>> # lazy value
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Option 5

    Lazy<T>

    works quite nicely in several situations, though option 1 should really be just fine for most projects so long as the developers aren’t idiots.

    Adding [EditorBrowsable(EditorBrowsableState.Never)] to the field won’t help if it is private since this logic only kicks in for intellisense generated from metadata rather than the current code (current project and anything done via project references rather than dlls).

    Note: Lazy<T> is not thread safe (this is good, there’s no point locking if you don’t need to) if you require thread safety either use one of the thread safe ones from Joe Duffy or the Parallel Exetensions CTP

    • 0