When does one make classes?

[jteow]

I've coded in AS 2.0 for about one and half years, and migrating to AS 3.0 has been very difficult specifically because I never really dabbled in creating my own classes as my projects have very limited scopes.

I understand that classes are great for reusability, encapsulation, and modularity. In spite of that, I'm still finding it hard to figure out when is a good scenario to use it.

[douglaae]

As you said, classes are great for reusability. My team and I have created several highly-interactive (code intensive) applications, and as the code base grew, it made sense to implement classes.

Here's an example: In our application, we developed custom tool tip functionality for rollovers on certain things, so we created a class to generate and display tooltips. Since only one tooltip can be displayed at one time, the methods of the class are static so that the class doesn't need to be instantiated.

Another example: We also have a common menu for all our applications. The menu has its own UI, so it's a separate .swf file. The code behind it is a class though with methods to control the display of certain menu items depending on which application is using it.

Yet another: We also have a "helper" class that has miscellaneous methods such as: a string trim method (made very easy with regular expressions support in AS3), a method to generate a "screen shot" by scanning through each pixel on the stage, and other miscellaneous items that are needed throughout our various apps.

As a best practice for programming, you never should duplicate code. Sometimes a local function is good enough, and it doesn't need to be shared amongst several code bases. However, for additional control over scope, classes are the way to go. Another great feature of OOP is inheritence. Flash allows you to base your custom classes off built-in classes like Sprite and MovieClip to name a couple. This means that you can create a custom class "BobbleHead" that will automatically inherit the features of a Sprite or MovieClip so that it leverage public properties such as x, y, alpha, etc.

I hope this helps!

Cheers,
Andy

[jteow]

Okay that does help a little bit as I see the advantages of it. However, I suppose my difficulty is comprehending how to architect a class when I have a "complex" object or movieclip.

[dthought]

I see classes a grouping of "like" ideas. Both properties which describe an idea, and methods which manipulate those properties.

A real-world correlation might be to use the classic example of the dog-as-class. A specific dog would be an instance of the dog class, and that may have properties such as hair colour and ferocity, as well as methods such as "sit" or "eat". It isn't as important to know how an instance of the dog class performs these tasks, just that they accept certain commands and return certain results.

A more practical example might be interface elements as douglaae suggests, or objects that exist on your stage such as, let's say a bouncing ball or a player sprite for a game.

By writing classes and the ecosystem of properties and methods around them, you create nice and reusable code. Just remember that it is recommended that you never directly manipulate properties (hence the get and set keywords to make property methods) and that you should never expect that a named instance of a given class exists (pass it as a reference if you require such functionality).

[jteow]

Just remember that it is recommended that you never directly manipulate properties (hence the get and set keywords to make property methods) and that you should never expect that a named instance of a given class exists (pass it as a reference if you require such functionality).

I was wondering if you could elaborate on this. What is the difference between directly manipulating a property, and using getters/setters?

[douglaae]

The "best practice" of not directly manipulating class properties that dthought puts forth is for safety. Say for instance you have a class called "BankAccount" with a property "_accountNumber". You would definitely want to use the "private" access modifier for _accountNumber because that data needs to be stored and retrieved in a secure manner. It's definitely easier to just declare _accountNumber as a "public", but that means that any code that can access the BankAccount class is able to see the value of _accountNumber which would probably be a security risk. So if you implement getter/setter methods, you would probably first validate the user's credentials before either reading or writing data to/from _accountNumber. This is the OOP concept of encapsulation/data hiding.

It's good to get in the habit of writing getters/setters so that when you're working for a bank, you don't wind up being fired because it's had all its account numbers stolen.

Cheers,
Andy