Of course you know about setters and getters, who doesn't? (If that's you, you might want to brush up on Object-Oriented Programming with my Introduction to OOP tutorial). But why use them? Why go to the trouble of creating extra functions to wrap around a property? Here are five reasons that are incredibly useful.
Personally, I use each of these reasons at least once a day..
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.
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Update me weeklyEnvato Tuts+ tutorials are translated into other languages by our community members—you can be involved too!
Translate this post