Good question! It this example, there is no real advantage, except encapsulation. The advantage comes in future changes.
Pretend at some point you want the property read only, just remove the set. Even more complex, say you want that propery only to be updateable if a certain criteria is met, you can have something like:
CODE
public string MyString {
get { return myString; }
set {
if (value == null) { throw new System.ArgumentNullException("MyString can't be null!"); }
if (value.Length<5) { throw new System.ArgumentException("MyString cannot be less than 5 characters."); }
myString = value;
}
}
Even if you never do this, you have the ability to and that's really the point. For instance, you may want to track all changes to an object at some point. You can put a logger in set or even attach it to an event.
This is part of a fundamental OO design principal of only exposing as much of an object as you need to. That way, you can add or change object code later without impacting the rest of the code that uses the object. If you see a public variable in an object, it's scope is ususally very small, otherwise extra code, like wrapping it in a property, should be written.
Hope this helps.
3 Mar, 2008 - 02:31 AM
| 