Properties vs Fields – Why Does it Matter? (Jonathan Aneja)

Properties vs Fields – Why Does it Matter? (Jonathan Aneja)

  • Comments 23

The other day I got an email from a developer asking an interesting question about VB10’s Auto-implemented Properties feature.

“I am, however, somewhat confused regarding the properties feature you mentioned - i.e. turning 11 lines of get/set/backing variable into one line. Wouldn't this be exactly the same as the existing functionality of creating a public variable? I see no benefit for using a property in this case, except perhaps for the sake of what some would consider best practice.”

On the surface there doesn’t seem to be a big difference between this:

Public Property Name() As String

And this:

Public Name() As String

Clearly both will expose an object’s state to the outside world, and can be read/modified using the exact same syntax. Which then begs the question, why would I ever use a property if I have no special logic in the Getter/Setter?

Let’s consider some reasons:

1. Fields can’t be used in Interfaces


You can’t enforce the existence of a field in an object’s public contract through an interface. For properties though it works fine.

2. Validation

While your application currently may not require any validation logic to set a particular value, changing business requirements may require inserting this logic later. At that point changing a field to a property is a breaking change for consumers of your API. (For example if someone was inspecting your class via reflection).

3. Binary Serialization

Changing a field to a property is a breaking change if you’re using binary serialization. Incidentally, this is one of the reasons VB10’s auto-implemented properties have a “bindable” backing field (i.e. you can express the name of the backing field in code) – that way, if you change an auto-implemented property to an expanded property, you can still maintain serialization compatibility by keeping the backing field name the same (in C# you’re forced to change it because it generates backing fields with unbindable names).

4. A lot of the .NET databinding infrastructure binds to properties but not fields

I’ve heard arguments on both sides as to whether or not that’s a good thing, but the reality is that’s the way it works right now.

5. Exposing a public field is an FxCop violation

For many of the reasons listed above :)


One argument I’ve heard for using fields over properties is that “fields are faster”, but for trivial properties that’s actually not true, as the CLR’s Just-In-Time (JIT) compiler will inline the property access and generate code that’s as efficient as accessing a field directly.

For these reasons and more, in most cases you’re better off using a property rather than exposing a public field. Thankfully VB10 will make this a lot easier :)

Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • I don't know how the VB compiler could handle some of these ideas...

    Property State() As String With {Public Get, Protected Set} = "MainMenu"

    Property State(Public Get, Protected Set) As String = "MainMenu"

    Or maybe using attributes...

    Property State() As <Get(Public), Set(Protected)> String = "MainMenu"

  • Of course in the attribute syntax thinks like Public and Protected would be values from an enum...

    Anyway, I'd prefer seeing things like yield, unsafe, unchecked and fixed than syntax that makes you write just a little less (which even so it's not that much thanks to snippets...).

  • So, like... This in C#:

    "public int Data { get; private set; }"

    Will still not be supported in VB?

    Why not?

  • visual basic book with a new one and I see you with the support of a professional code of the process to be preparing ...

  • for you thanks vbteam

  • I tried to do a conversion of C# to vb9. It worked beautifully till the get/set dilemma. Gotta figure something out new. So here I am in basic writing basic to solve basic and not my problem. Sheesh.

  • how to use visual basic field code to c#

  • it is recommended to wrap fields of a class with properties, get,set in C# and keep fields private. By doing this object fields are safe and we can do some processing, event invocation, validation etc.

    In C# 3.0 AutoProperty is introduced in which we do not need to declare field separately, we have to just write property with modified syntax. C# 3.0 and above compiler will generate a private field automatically into compiled assembly.

    Inside il code it is just like get set method.

Page 2 of 2 (23 items) 12