Whenever there is question about credibility of Properties, I see that most of the discussion happens around functions/methods vs properties. But I would also like to know the compelling reason to use property with associated private field vs public field directly itself, incase of most common get/set behaviors with no other processing, I mean this way
public string CustomerName;
vs
private string customerName;
public string CustomerName
{
get{return customerName;}
set(string value){this.customerName=value;}
}
Properties expose fields. Fields should (almost always) be kept private to a class and accessed via get and set properties. Properties provide a level of abstraction allowing you to change the fields while not affecting the external way they are accessed by the things that use your class.
A field is a variable, a property is a syntactic sugar for two methods - a getter and a setter - which get called when you access the property instead of accessing the content of the variable directly.
Properties can be marked as public , private , protected , internal , protected internal , or private protected . These access modifiers define how users of the class can access the property.
Properties can be read-write (they have both a get and a set accessor), read-only (they have a get accessor but no set accessor), or write-only (they have a set accessor, but no get accessor). Write-only properties are rare and are most commonly used to restrict access to sensitive data.
You get source/binary compatibility if you later need to add other behavior, you get to add break points, and it's just philosophically cleaner (care about the behavior, not the storage mechanism).
Note that you don't need the whole of the latter block in C# 3:
public string CustomerName { get; set; }
See my article on "Why Properties Matter" for more information.
You can override or at least create a "new" property in a derived class
At this point people expect properties to be exposed and fields to be hidden. If someone's going to reflect over your class (its becoming more and more common with tools like Castle Windsor, NHibernate) there is a world of difference, they will likely not be checking for exposed fields.
This is mostly a bug in Java. In many other languages (Python, Delphi, Groovy), the compiler will generate the getters and setters for you unless you supply the code.
This means you can use a "public" field in Groovy and the compiler will silently generate and invoke the setter/setter. If you need to do additional magic when a field is changed, you can introduce a specialized setter and everything will work.
It's one of those things where reality clashes with a design. The Java designers didn't want the compiler to do anything you can't see. What seemed like a good idea many years ago, didn't turn out too well.
I notice one helpful use of property. If you are going to bind the collection of your object to a DataGrid or DataGridView or other bindable control, the only recognized evaluatable names are Property and not public fields.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With