Difference between Fields and Properties

  • Thread starter Thread starter Rafael Veronezi
  • Start date Start date
R

Rafael Veronezi

Hello people,
It's clear to me that the great difference between fields and properties, is
that with properties you can write code to the routines that assign and
return the values, wich is in fact recorded in a private field (the common
scenario)...
My question is...
It's common to see people that constructs properties that could work
perfectly like a field... For example, I have two properties, name and
email:
(C#)
public class MyClass
{
private string _Name;
private string _Email;

public string Name
{
get { return _Name; }
set { _Name = value; }
}

public string Email
{
get { return _Email; }
set { _Name = value; }
}
}

Ok, it's well declared... I took long writing that code to explain well my
question, is, what is the advantage using properties in a case like this,
where the class would work exatcly the same declaring Name and Email
directly public fields?
Thanks,
Rafa
 
It has generally not been a good idea to allow public access to fields (Java
standardizes on having GetXXX and SetXXX), since the code owning the field
has no control over how it's used. Properties are merely an abstraction of
fields such that you still get to control access, but they appear like
fields. So basically, the primary advantage is control over the value.
Collections are particularly nice because you can do stuff like:
public ArrayList MyCollection {
get {
if (this._MyCollection == null) {
this._MyCollection = new ArrayList();
}
return this._MyCollection;
}
}

So now, you've abstracted away the concept of initialization (although you
still would want to .Clear() it occasionally) into the property as well as
guaranteed (by preventing setting of the value) never getting a
NullReferenceException.
For me, I *always* make my fields private and only access them within the
property, even if I need it elsewhere in the class, as I want my control
centralized, and it also makes it easier to debug when something is getting
set, because it only gets set in one place, and it is within something you
can debug: a method (a property is internally a method)
 
Yikes! Mainly, if you made them public, you just broke encapsulation which
is one of the cardinal rules of OOP.

2) You can't validate the values from within the class. In Name, you could
put an If Statement in there to not allow 5000 Character names...if you use
public properties instead, the client code will need to validate it or it
won't be validated at all. This is a huge and unfair burden to put on
people using your code, even if you are the only one using it. Definetly an
accident waiting to happen.

3) You can attach events to properties very easily...not the case with
public variables. For instance, how many times do you use an event like the
TextBox's text_changed event? If text wasn't a property, but instead was
public member, good luck accomplishing this. even ifyou could, it'd be a
real burden on the developer. On the other hand, inside the Set of my
Property, all I have to do is Raise TextChanged because anytime that's
getting called, the text is changing.

4) Versioning the class can be a problem. You can't change the members
without breaking binary compatibility. You also can't change them into
properties without breaking binary compatibility. I've never had occassion
to do this but that's what the gurus have said and I take their word for it.

5) Every one will make fun of you except VB6 programmers (just kidding)

HTH,

Bill
 
Rafael Veronezi said:
Hello people,
It's clear to me that the great difference between fields and properties, is
that with properties you can write code to the routines that assign and
return the values, wich is in fact recorded in a private field (the common
scenario)...
My question is...
It's common to see people that constructs properties that could work
perfectly like a field... For example, I have two properties, name and
email:
(C#)
public class MyClass
{
private string _Name;
private string _Email;

public string Name
{
get { return _Name; }
set { _Name = value; }
}

public string Email
{
get { return _Email; }
set { _Name = value; }
}
}

Ok, it's well declared... I took long writing that code to explain well my
question, is, what is the advantage using properties in a case like this,
where the class would work exatcly the same declaring Name and Email
directly public fields?
Click to expand...

The main practical difference is the future. You may not require any
validation today, but tomorrow you might. You might also need to store the
property value somewhere other than in a private field. You might need to
delegate the property to a similar property in a separate class.

If you use properties, you can make any of these changes, and the code which
uses your property will never need to know.

Also, there are some cases where only public properties can be serialized.
Similarly, you can't data bind to a field, only to a property.
 
Back
Top