Public, Private, Protected, Internal: Access Modifiers in AS3

Wow, I really went away for a while. Between working, wedding planning and the holidays I really lost track of posting! Ohhh where to begin again :) . Since I have gotten a number of questions regarding access modifiers in AS3, thats seems a good place to start.

What is an access modifier?

Just as it sounds, an access modifier modifies what Classes can instantiate a particular Class or access one of its properties. Not to use a phrase to define itself, but that’s really all there is to it. For example, if I have a class Foo and it has a method bar ( that returns a Beer of course, what else would a bar method do!?!? ) I have to make a decision regarding what other objects in my application should be able to request a Beer from my Foo.bar method. I have some options: I can allow all my other classes access to it, I can allow only classes in Foo‘s package access to it, I can allow only subclasses of Foo access to it, or I can not allow any other classes access to it. It all comes down to what access modifier I give the method. Some examples:

public access modifier allows every Class access

// hey everyone, beer is on me!!!
public function bar():Beer { ... }

internal access modifier allows Classes sharing this package access

//my good package-mates, have some beer on me!
internal function bar():Beer { ... }

protected access modifier allows subclasses access

// I will only give beer to my children ( they are 21, i swear! )
protected function bar():Beer { ... }

private access modifier allows no external access

// My beer is just that, MINE!
private function bar():Beer { ... }

So there are a few different types of access modifiers in AS3, the real question becomes when to use each type. And for my totally unambiguous answer: it depends.

The default access modifier is internal, meaning that if you don’t define an access modifier like so:

function bar():Beer { … }

Classes that share this package will have access to the properties, but no other Classes will. While its perfectly fine to not declare an access modifier if you really want it to be internal its just good form to always declare your modifier. It’ll keep your co-workers from ridiculing you over your lack of tact :).

Note: In AS3, the protected and private access modifiers are only allowed to be used for a Class’ properties and methods, not the Class itself.

My preference is to always declare my properties and methods private unless the need arises to allow other Classes access. The more abstracted you can keep the inner workings of your Classes the better, because they will be more loosely coupled to other Classes and therefore more reusable and extensible. I almost never declare a variable as public, but will use implicit getters and setters to emulate a readable/writable class property.

To recap:
* Properties and methods control what external Classes have access to them.
* Access modifiers of properties and methods can be public, internal, protected or private.
* Access modifiers of Classes can only be public or internal.
* The default access modifier in AS3 is internal

24 Responses to 'Public, Private, Protected, Internal: Access Modifiers in AS3'

  1. Rob says:

    Thanks for the great explanation of Access modifiers in AS3. Anything related to beer is easy for me to understand! I enjoyed your sense of humor and learned a lot. Keep up the good work.

  2. Thanks for this, I had noticed that ‘private’ didn’t allow access to subclasses and was about to just declare everything ‘public’ when I found your article. Nicely explained :)

  3. kenneth says:

    can you give me some program example of default access modifier, public access modifier, private access modifier, protected access modifier?
    please….hope you’ll understand..

  4. Jonathan says:

    Hey Kenneth, I’m not quite sure what you are asking for. Are you asking what would be an appropriate use of each type of modifier?

  5. Caz says:

    “private access modifier allows subclasses access”

    think this is a typo! Great article though.

  6. Jonathan says:

    yes, yes it is! thanks for catching that, i have updated the article.

  7. Mike says:

    mmmmmm, all this does is encourage binge drinking!!!

  8. mike says:

    brb ..fridge

    nice article!

  9. April says:

    Perfect! Thanks!

  10. j says:

    Beer actually made things easier to understand for once!

    • Tiia says:

      peter james i understand, and you’re kind of mankig my point for me I soetimes get the feeling that thing’s aren’t being thought out, and the use of private’ is just a lingering AS 2 habit. I’m certainly not talking about exposing everything’, what I’m talking about is realizing that many times, you’d want to sublcass over composition (i don’t agree that you should just blindly favor composition over inheritance you go with what’s appropriate). Take the case of extending a component I would want to create a subclass of that component rather than create another class which uses that component. In many of the AS 3 components I have dug through so far, the use of private has seemed overkill, when protected would have been more appropriate.

  11. Colin says:

    Very nice! I’ll be seeing you on intervention on Monday.

  12. VK says:

    Excellently explanation! I was looking for that Note which said classes can have only public and internal access modifiers. I got that Note from you :)

  13. IneedHelp says:

    THANK YOU FOR THE INFORMATION!
    If you want to, I will have your children.

  14. ,mahesh says:

    Excellently explanation! ,Thank you i know only public and private.Now i got a all types of classes,thnaks you very much

  15. mahesh says:

    Excellently explanation!

  16. Kendall says:

    Thank you very much for this explanation!

  17. JeyJey says:

    thanks dude it gave me a huge boost. thanks

  18. Marcos Vasconcelos says:

    Where is the share buttons? love theses explication!

  19. Michael says:

    You should point out that these access modifiers are total rubbish- public means only available in the the class it was created in otherwise it will give you undefined variable error- same for the others.

  20. Um diese Sicherheit und unseren Kundenservice zu gewährleisten, haben wir für Veranstaltungen wie z.B.
    Mindestteilnehmerzahl sechs Kinder (inkl. Die Kinder begeben sich auf dem Museumsschiff auf eine spannende Fotorallye durchs Schiff oder erwerben ein
    Schifferpatent.

  21. Loren Helgeson says:

    Thank you for the explanation. I’ve done several tuts on AS3, and people tend to just gloss over this subject. I didn’t even know “protected” was an option.

  22. PeterP says:

    Access modifiers are a nuisance. Not in general, but in their typical implementation. That’s especially true for AS3, bu talso Java and others.

    As Tiia pointed out, private elements are often unnecessarily so. If you want to subclass a class just to make a simple change, you often have to copy the class because you cannot access vital parts.
    If things are protected, that’s good for the idea of object-oriented programming and inheritage. IMHO it should be the default. I guess it isn’t because a possible overload of inherited elements, with the high risk of ambiguity.
    Using internal is nice for sharing functions that are only to be shared in a package. However, same package means same source folder and prevents access from classes in a subdirectory (and therefore a different package) as well as from subclasses outside the same package.

    There is no way to combine internal and protected, so you will often end-up to make everything either public or (where it really fits) private. Or you create a protected function and an internal wrapper. And for variables, you have a private variable, a protected getter/setter and an internal wrapper to the protected getter/setter.
    In fact, this seems the best way to control access (the internal wrapper could omit the setter method, making the variable read-only for other package members) while keeping all the advantages of inhertance.

    And if you don’t want your class to be subclassed or method to be overridden, then you can always declare it as final.

Trackbacks/Pingbacks
  1. […] MovieClip class in line 3), our new class inherits every public (or protected — more on that here) method and property. Of course, this means that at the minute LoopingMovieClip has no […]

Leave a Reply to IneedHelp Cancel reply

Your email address will not be published. Required fields are marked *

*