Answer.

Background
Properties in Visual Basic allow for encapsulation of the logic for getting and setting values. With the introduction of properties, the code becomes more readable and safer, eliminating the need for direct access to class fields and making it easier to implement validation or calculation logic directly in objects.

Problem
Beginners often make fields public or use auto-properties without getters/setters containing logic, which leads to breaking encapsulation or the inability to implement calculated values. Another issue is a recursive call to the property within itself, leading to a StackOverflow.

Solution
In Visual Basic, a private field is declared, and the property includes Get and Set blocks with the necessary logic. Calculated properties only use Get, returning a computed value based on private fields. Inside the set block, always refer to the private field to avoid infinite recursion.

Example code:

Private _price As Decimal
Private _quantity As Integer

Public Property Total As Decimal
    Get
        Return _price * _quantity ' calculated property
    End Get
End Property

Public Property Price As Decimal
    Get
        Return _price
    End Get
    Set(value As Decimal)
        If value < 0 Then Throw New ArgumentException("Price must be positive")
        _price = value
    End Set
End Property

Key features:

Encapsulation of access to internal data.
Ability to add validation logic or additional processing when getting/setting.
Distinction between read-only and write properties.

Trick Questions.

Can you access the Name property within the Set Price if it is also implemented via a private field?

Yes, if within the set block of the Price property you access another property (for example, Name), this is allowed, as calls to different private fields do not cause recursion. Avoid referring to itself: calling Price within Set Price would trigger recursion.

Example code:

Public Property Name As String
    Get
        Return _name
    End Get
    Set(value As String)
        _name = value
    End Set
End Property

Public Property Price As Decimal
    Get
        Return _price
    End Get
    Set(value As Decimal)
        If Name Is Nothing Then _name = "default"
        _price = value
    End Set
End Property

What happens if you invoke this property again inside the Get block?

This will lead to infinite recursion and StackOverflow. In the get block, always use the private field; otherwise, the property will call itself.

Public Property Amount As Decimal
    Get
        Return Amount ' will lead to infinite recursion
    End Get
    Set(value As Decimal)
        _amount = value
    End Set
End Property

Can a property be declared as WriteOnly and what are the dangers of it?

There are WriteOnly properties, but it's not recommended to use them, as the object loses the ability to return a value, which diminishes readability and predictability. If it's needed only for writing — it's better to reconsider the architecture.

Private _secret As String
Public WriteOnly Property Secret As String
    Set(value As String)
        _secret = value ' Can write, but cannot read.
    End Set
End Property

Common Mistakes and Anti-Patterns

Recursive calling of a property within itself instead of referring to a private field.
Public fields instead of properties, which breaks encapsulation.
Creating WriteOnly properties without a clear necessity.
Lack of input validation in the set block.

Real-Life Example

Negative Case

A programmer decided to make the Price field public and worked directly with it. As a result, Price sometimes became negative by mistake.

Pros:

Quick implementation, minimal code.

Cons:

No encapsulation.
Validation logic impossible.
Easy to introduce invalid values.

Positive Case

A colleague replaced Price with a property containing a private field and validation in the set block, which prevented incorrect values.