AS3 101: Quick Tip – Use Access Modifiers Effectively

There are four access modifiers you can choose from when declaring properties and methods: private, protected, internal, and public. How do you know which one to use?

Before I answer that question, let’s consider why we’d bother with private (and protected and internal) and not just make everything public? Well, there’s a little thing called encapsulation in Object-Oriented Programming. The idea behind it is the “black box” design of classes. You don’t need to know how the box works for it to do its job. Take a car, for instance. You don’t need to know the first thing about how an engine works for you to sit in the driver’s seat and make the car move. The inner workings of the car are encapsulated, and all you need to be familiar with is what can you do from the outside (such as work the pedals and turn the wheel; who cares how the wheels turn when you hit the gas, just so long as they do?).

In fact, making the engine more public could lead to problems; if someone who doesn’t really know what they’re doing starts messing around, we might have a broken car on our hands. With that in mind, let us consider…

The First Rule

It’s more of a guideline than a rule, but you should make properties and methods as inaccessible as you can. It’s much easier to change your mind later and provide expanded access than it is to go the other direction.

For example, imagine a class that has a “foo()” method. If we start out making foo() public, then any other object can call it. Now, we decide that, for whatever reason, foo() really should only be called under controlled circumstances, so we want to make it private. At the point of changing “public” to “private,” there could be any number of other objects already calling foo(), because it’s public. Once we make the switch, we run the risk of breaking existing code.

On the other hand, suppose there was a “bar()” method that we originally wrote as private, and the only place where we can call bar() is from within the object itself. But we have since decided that bar() is really the heart and soul of this object, and we could really make things wonderful by making it public. As we make the change, we know that the only code that could previously call bar() will still be able to call it after the change.

The Other Rule

This one is probably more steadfast than the first one, but again, there’s no rulebook out there, nor is there an enforcement agency that will bust you should break these “rules.” However, it’s a good idea to always always always make your properties private, or at the most protected. Never make a public property.

Why? In a nutshell, because you don’t want some other bit of code changing the value of your properties without you knowing about it. This isn’t some paranoid, “Big Brother is always watching” approach to programming. But it is about control.

This is not to say that there should never be public access to the value. Instead, it’s to say that we should control public access to the value. Consider: what if your object had a String property that held one of three possible values, and the object behaved slightly differently depending on the state of that property? For instance:

public var state:String;
public function foo():void {
    switch (state) {
        case "A":
            trace("foo - a");
            break;
        case "B":
            trace("foo - b");
            break;
        case "C":
            trace("foo - c");
            break;
    }
}

And in using it:

myObject.state = "A";
myObject.foo() // traces "foo - a";
myObject.state = "B";
myObject.foo() // traces "foo - b";

Now, if you happened to write:

myObject.state = "a";
myObject.foo() // nothing happens!

Then the state is never matched. Sure, you can add a default to the switch statement, and even perform a toUppercase() on the state property when evaluating it, but it would be better to simply validate the value as it’s being set.

Writing a public setter for the property allows you the opportunity to examine the incoming value and react accordingly.

private var _state:String;
public function set state(value:String):void {
    if (value == "A" || value == "B" || value == "C") {
        _state == value;
    } else {
        throw new Error("Invalid value set for state: " + value);
    }
}

Of course, you can handle that however you want, and that’s the beauty of private properties combined with public setters and getters.

And, to tie back to the first rule, it’s a “safe” change to have a private property for which you later add public setters and getters.

See my quick tip on Setters and Getters for more information.