locked
Differences Between Properties and Variables in .Net RRS feed

  • Question

  • I have gone through the differences but still those are not pretty much clear to me.

    Can anyone pls help?

    Thursday, May 26, 2011 9:34 AM

Answers

  • First, "variable" is not the right word.  You mean a field:

    public class A { public string Field; }
    

    A variable is specifically an identifier that is local to a method, like this:

    public void F()
    {
      string variable = "my variable";
    }
    

    You should never use a public field in .NET.  You should always use properties, even when you don't need to write any code to be executed before getting the value or before setting the value.  The only time you should use fields is when they are private (not protected, not internal, not protected internal).

    There are a lot of reasons that I don't have time to go into here.

    Any time you need to declare a public data member of a class, you can declare it like this:

    public class MyClass
    {
      public string MyProperty { get; set; }
    }
    

    You don't need to flesh out the get and set bodies.  If you declare a property like this, the compiler will automatically generate a private member for this property.  It will essentially translate it to this:

    public class MyClass
    {
      public string MyProperty
     {
       get { return _myProperty; }
       set { _myProperty = value; }
     }
     private string _myProperty;
    }
    

    (You should never write a block like above.  It needlessly clutters the code.)

    One of the major reasons that declaring an auto-generated property is superior to declaring a private field yourself is that when you let the compiler auto-generate your property, you can't ever reference the private field.  If you do it yourself, you can.  This means that inside your class, you could either write MyProperty = "some value"; or _myProperty = "some value".  Now, when you're trying to debug an issue where MyProperty has the wrong value, instead of finding every instance where MyProperty is on the left hand side of an assignment operator, you also need to check _myProperty, because these two identifiers are essentially aliases to the same value.  You should always avoid creating two identiifers for the same data.  It's disasterously poor design.

    Evan

    • Proposed as answer by RaheelKhan Thursday, May 26, 2011 2:47 PM
    • Marked as answer by Tiya01 Friday, May 27, 2011 1:55 AM
    Thursday, May 26, 2011 11:57 AM

All replies

  • Hello,

    this very easy to explain. With properties You can make more complex things which we need in the OOP. By assigned a value to the property txt the code block between set ... end set will be executed. Note from the outside of the class a property seems to be a normal variable. You can also do this with the public variable _txt. But no code will be executed automatically. Another difference in my sample is: Into txt You can only write but not read. A public variable has no protection.

    There ara a lot of other explanations. But with this one I had a "click event" in my head.

    best regards Ellen

     

     

    Public Class Form2
      Public _txt As String
      Public WriteOnly Property txt() As String
        Set(ByVal value As String)
    
          Me.TextBox2.Text = value
          Form1.TextBox1.Text = "message received"
    
        End Set
      End Property
    
      Public WriteOnly Property txtHide() As String
        Set(ByVal value As String)
          Me._txt = value
          Form1.TextBox1.Text = "message hidden"
        End Set
      End Property
    
    End Class
    

    Ich benutze/ I'm using VB2008 & VB2010
    Thursday, May 26, 2011 11:14 AM
  • First, "variable" is not the right word.  You mean a field:

    public class A { public string Field; }
    

    A variable is specifically an identifier that is local to a method, like this:

    public void F()
    {
      string variable = "my variable";
    }
    

    You should never use a public field in .NET.  You should always use properties, even when you don't need to write any code to be executed before getting the value or before setting the value.  The only time you should use fields is when they are private (not protected, not internal, not protected internal).

    There are a lot of reasons that I don't have time to go into here.

    Any time you need to declare a public data member of a class, you can declare it like this:

    public class MyClass
    {
      public string MyProperty { get; set; }
    }
    

    You don't need to flesh out the get and set bodies.  If you declare a property like this, the compiler will automatically generate a private member for this property.  It will essentially translate it to this:

    public class MyClass
    {
      public string MyProperty
     {
       get { return _myProperty; }
       set { _myProperty = value; }
     }
     private string _myProperty;
    }
    

    (You should never write a block like above.  It needlessly clutters the code.)

    One of the major reasons that declaring an auto-generated property is superior to declaring a private field yourself is that when you let the compiler auto-generate your property, you can't ever reference the private field.  If you do it yourself, you can.  This means that inside your class, you could either write MyProperty = "some value"; or _myProperty = "some value".  Now, when you're trying to debug an issue where MyProperty has the wrong value, instead of finding every instance where MyProperty is on the left hand side of an assignment operator, you also need to check _myProperty, because these two identifiers are essentially aliases to the same value.  You should always avoid creating two identiifers for the same data.  It's disasterously poor design.

    Evan

    • Proposed as answer by RaheelKhan Thursday, May 26, 2011 2:47 PM
    • Marked as answer by Tiya01 Friday, May 27, 2011 1:55 AM
    Thursday, May 26, 2011 11:57 AM
  • Thanks Evan.

     

    Friday, May 27, 2011 2:05 AM