The standard method of implementing get and set accessors in C# and VB.NET is to use a public property to set and retrieve the value of a corresponding private variable. Am I right in saying that this has no effect of different instances of a variable? By this I mean, if there are different instantiations of an object, then those instances and their properties are completely independent right? So I think my understanding is correct that setting a private variable is just a construct to be able to implement the get and set pattern? Never been 100% sure about this.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
You are correct up to this question:
Quite the opposite is true. Ideally, only the encapsulating object should have direct access to the object(s) it encapsulates. This is known as the Law of Demeter.
In reality, following this "law" (like most programming laws) religiously can lead to over-engineering, but it is a very good principle to bear in mind.
Make the mental shift so you have to justify the existence of a getter, and separately a setter, before you blindly implement them for all private fields.
Yes, you are right.
Not sure what you mean by that.
It is not true. Private setters are encapsulating value and DO NOT allow direct access to the property of the class. It is one of the programming principles widely used in Domain driven development.
You can think of a property as a method that can do much more then just expose the underlying field. A property can also provide access to more than one private field.
For example, you could have an
This way you are encapsulating the inner workings of the invoice and exposing just this simple property. In the
Moreover, you could make the property readonly (no
I find it more helpful to think of properties as methods, rather than fields, and working with properties allows you to change how the data is returned without changing every call to that property (because you can process the field before returning, rather then outright giving the field to the client).
If you look at the Intermediate Language of the setter below:
Then you'll see:
Now if you ignore everything within braces, you'll see that it works similar to normal methods in your class. You can think of getters and setters as sugar syntax.
There is a whole separate discussion of when you should be using properties instead of methods, and what access modifier they should have, but it's out of this question's scope.
Finally, you class is just a blueprint. Once you instantiate an object from your blueprint (class), its logic is encapsulated, therefore accessing properties on this object doesn't affect other objects that have been instantiated from the same class.
OK sorry - on re-reading my question wasn't 100% clear, so here's the combined explanation on use of get/set to help others who want to know the rationale of using this pattern (thanks PDR - I've upvoted your response which was the most useful in constructing this explanation):