Question

I have always tried to follow principles of encapsulation when coding. For example, doing this:

public class Student

private Name As String

public sub setName(ByVal name2 As String)
  Name = Name2
End Public

Instead of allowing clients to access properties directly, like:

Dim s1 As Student
s1.Name = "Mark"

All the books say it is bad practice to follow option two as it means client code could break if you change the class. However, I don’t fully understand why this is the case. If you remove the Name member then client code will break regardless of whether you allow them to access the property directly or not. What am I missing?

Answer 1

In simple terms, Name is not binary compatible with a property or method signature returning String. So if you create a public member, and then change it to a property later, it will break any client code that originally called the member.

More info here: http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx

Other reasons:

• You get more fine-grained access control with properties.
• You can add breakpoints to properties.
• You can add logging to properties.
• You can add validation to properties.
• Properties are used for data binding; fields aren’t.