Reason 1: You can create read-only (or write-only) properties
By making the actual property private, and writing just a public getter (with no matching setter), you can provide access to reading the value, but disallowing changing the value from outside the class. This is useful for Immutable Value Objects that carry a bunch of data, but should never be changed once created. That, and around 500 other reasons to use read-only properties.
Reason 2: You can perform validation and auto-correct incoming values
Numeric properties oftentimes require a number between a certain set of values, or that is rounded to a certain precision. You can do this limiting or rounding in the setter to ensure clean values, or, if required, you could do this processing “on the fly” in the getter, in order to store a full-precision value internally, but provide a clean value to the outside.
Similarly you can provide default values or handle null values with a bit of logic. Suppose you have a Person object, with firstName and lastName properties. Let’s say that the business logic of the application dictates that these properties cannot be null. They can be empty Strings, but they can’t be null (because, oh, let’s say we’ll be running some regular expression searches on them and it would just be a lot easier to be certain that the String exists, rather than always checking for null).
So, in your setter, you might have something like this:
public function set firstName(s:String):void {
if (!s) s = "";
_firstName = s;
}
If you’re thinking that you could accomplish this with default values on arguments, then you should look up compiler error #1123: “A setter definition cannot have optional parameters.”
Reason 3: You can synthesize data
Imagine that same Person object from the last reason, with its firstName and lastName properties. To also implement a fullName property, you could create an actual property, and make sure you update fullName every time you set the firstName and/or lastName properties. Or you could simply create a fullName getter that returns an automatic concatenation of the first and last names:
public function get fullName():String {
return firstName + " " + lastName;
}
Reason 4: You can hide more significant logic behind a simple property
You could have a Button class that encapsulates a Sprite and handles much of the interactivity. An “active” setter could take a simple Boolean value and turn it into more complex logic that adds or removes event listeners, enables or disables the hand cursor, and turns on or off the mouseEnabled property of the Sprite.
Reason 5: You can instigate visual changes from a property change
This follows along from the last reason. What if you had Slider object, that was represented on-screen by, you know, a slider interface element. Suppose this object has a “value” property. By implementing a setter for the value, you can not only set the actual property to that number, but you can then also update the visual elements necessary to make the slider’s drag handle move to the appropriate position.
As a bonus feature, implementing it this way would also allow you to use a tweening engine on the Slider object, and tween the value. Most tweening engines allow you to tween any numeric property on any object, even properties that are really setters and getters.
source : http://active.tutsplus.com
be successful 
You might also like
 |
 |
 |
 |
