Why to use GET & SET methods while defining properties in VB.Net?

Question

I am bit confused over the need to use GET & SET methods in VB.net. I want to discuss two cases in this connection: firstly when we declare the property as PUBLIC and next when we declare the property as PRIVATE.

What is I find is when I define a property as public I can directly set and access the values of that property without using the GET/SET methods --- quite simple: See below

Module Program
    Sub Main()
        Dim t As New test()
        t.name = "Roy" 'Label 1
        Console.WriteLine("t.name = {0}", t.name)
        Console.ReadLine()
    End Sub
End Module

Class test
    Public Property name() As String
End Class

When I declare that same property as private, as shown below, I can still set and access the value of private property by simply using a constructor and a public subroutine. See below:

Module Program
    Sub Main()
        Dim t As New test()
        t.printValue()
        Console.ReadLine()
    End Sub
End Module

Class test    
    Private Property Name() As String 
    Sub New()
        Name = "Roy" 'Label 2
    End Sub

    Public Sub printValue()
        Console.WriteLine("Value stored in NAME is: {0}", Name)
    End Sub
End Class

So my question is why at all do we need to use the GET/SET methods? I understand that whenever an assignment happens to a property the SET method is implicitly called...but can you please help me understand cases where we MUST explicitly use the GET/SET methods? Or it is that using GET/SET is more of a choice? Validation is one thing that can be added easily at a later stage if one uses GET/SET but then is that the only reason? PLs give your views.

Also, I came across the following two related questions in stackoverflow (for different languages though): Links below:

Why to use getter and setter methods to set class properties?

Why use getters and setters/accessors?

But i could not understand most of the reasons justifying the usage of the GET/SET methods. For example if we dont use the GET/SET method then we are exposing the property to the outside world - meaning it can be directly accessed from outside the class. But then this is true only for PUBLIC properties as PRIVATE properties cannot be directly accessed from outside the class. Similarly in the second link the author mentions the following as a reason to use GET/SET: Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages. What exactly does this mean --- any simple real life example?

Answer 1

A property is a wrapper around a field, i.e., a class or struct variable. It provides a getter and/or a setter method to access this variable. (You can also have a read-only property returning the result of a simple evaluation not bound to a single field.)

The getters and setters are implicitly called when reading from, respectively writing to properties.

So, the question is not whether to use getters and setters or not, but whether to access fields directly or via a property.

You can declare a property like this, by declaring a field and writing the getter and setter explicitly.

Private _prop1 As String ' Backing field
Public Property Prop1() As String
    Get
        Return _prop1
    End Get
    Set(ByVal value As String)
        _prop1 = value
    End Set
End Property

or use an Auto-Implemented Property

Public Property Prop1 As String

Both declarations are equivalent. The auto-implemented property implicitly declares a backing field and implements the getter and the setter accordingly.

It can make sense to declare a property as private when you use it only inside the class where it is declared. This still provides the advantages described in the links you provided because this property still hides the details of accessing a field, does validations, etc.; however, it does not forbid the direct access to the backing field inside the class. So, you need to be more disciplined with private properties.

---

What does a property mean for debugging? You can easily set a breakpoint inside a getter or setter to detect accesses to a property. You cannot set a breakpoint on a field because a field is never executed. It is just a declaration.

You can also add a System.Diagnostics.Debug.Writeline("=====> test") (writes to the Output window) or do some logging in getters and setters.

See also: Tutorial: Learn to debug Visual Basic code using Visual Studio

---

When using Windows Forms Data Binding or WPF Data Binding properties are required. They also allow change notification.

Answer 2

Dynamically Calculated Values

I didn't read those links, but one reason you might want to implement your own getters & setters is that you may want to return something that requires some type of calculation or manipulation. For example, suppose you have item Sale with properties RawPrice, SalesTax, and FinalPrice. However, you need/choose to dynamically calculate the final price (based on variable sales tax) each time. So you first set the RawPrice, and then query FinalPrice, which returns RawPrice + SalesTax, but SalesTax gets dynamically calculated based on some other property like country of origin etc.

Alternate View of Data

Another reason you might want to do this is to provide another view of the same core data. For example, if your data was an HTML page, perhaps one property returns the normal string value, while another "no-HTML" Property has a custom Getter that performs some regex to remove all HTML tags and return a plain-text variation. This allows you to keep all related code inside of a sub-assembly, rather than having your main program do various manipulations.

Code Portability

This can make your life a lot easier down the road because of code portability. Your code is now more easily re-usable in other projects, since all you need is that one assembly.

Private Variables vs Properties

If I'm doing something that calls for a class with properties like that, there's good chances it's going to have methods, too. Those methods are almost always going to require creating private variables that nothing outside the assembly needs to know about. However, in such cases, they are not going to be private properties but rather simply private variables. For example, instead of Private Property Name() As String, with its implied auto-implemented backer variables with getters & setters, I would instead just say Private Name() As String, which would be equivalent to Dim Name() As String. You can use variables, constants etc. within your class just as you normally would, and, by default, the rest of the world won't know anything about them.

I'm not sure why you'd use a private Property. Maybe there's a good reason; I just don't know what it is. Most of the time, a private variable is probably what you really want. If you think there's a reason that you actually need a Private Property, I'm curious to hear your thinking on it. (I'm always open to a new way of thinking!)

History

Auto-implemented properties were not present in Visual Basic .NET for many years. In the past, you had no choice but to use GET/SET. So it's a more recent development for VB.NET to be able to simply declare a property as you do in your first code example, and for the runtime to automatically generate the backer variables.