Question

I primarily work in Java, but I’ve recently started using ActionScript 3.0 for a multi-player Flash game that I am helping to develop. The project is in it’s early stages, so I’m still working on the class structure. I keep running into limitations with the ActionScript language when I try to use many of the OOP features I expect in Java.

For example:

• I need an abstract Character class. There is no reason why Character would ever be instantiated, but ActionScript doesn’t support abstract classes. As a result my code has this comment at the top:

Character should be an abstract class,
but AS doesn’t support abstract
classes.

DO NOT CREATE AN INSTANCE
OF THIS CLASS. (Only instantiate
classes that extend this one (ex.
Player, Zombie))

• As a result of the design of Flixel (the library we are using), I need to have a CharacterGroup class with an inner class Character so that a CharacterGroup can also contain other sprites like guns and stuff. In Java, I would use an inner class. ActionScript doesn’t support inner classes. There is something called a “helper class”, but helper classes are not inherited, which makes them useless in this context.

My question is this: Is ActionScript’s ability to deal with OOP design just less developed or am finding ActionScript so frustrating because I am trying to write it as if it were Java instead of working my head around how ActionScript was desinged?

In other words, is the “correct” way of doing OO design different in ActionScript than it is in Java?

(Note: I’m not asking for opinions about why ActionScript is better/worse than Java. I’m only asking if I am coding correctly or trying to pull too much of my experience from Java.)

Thanks!

Answer 1

AS3 is not missing features and you cannot define it as ‘less developed’.

Firstly for your problem – there are ways around the abstract class methodology.
For your abstract class Character – you can make it so the user developer receives an error on trying to instantiate it.

package com.strangemother.database.abstract
{ 

    public class CentralDispatch extends EventDispatcher
    {
        private static var _centralDispatch:CentralDispatch;


        public static function getInstance():CentralDispatch
        {
            if(!_centralDispatch)
                _centralDispatch = new CentralDispatch(SingletonLock);

            return _centralDispatch;

        }

        public function CentralDispatch(lock:Class)
        {
            if(!lock is SingletonLock)
            {
                throw new Error("CentralDispatch is a singleton. Use CentralDispatch.getInstance() to use.");
            }
        }

    }
}

internal class SingletonLock{}

AS you can see – this must be used by the ‘.getInstance Method’ – but to extend of that, only this class can make a new instace of itself as its the only class of which can see the internal class ‘SingletonLock{}’.
For your purpose – you may remove the ‘getInstance()’ method and force another way the user to receive an instance of this class.

This should also display the ability to make internal classes. These cannot be seen by any other class – only this package and the parent class CentralDispatch can use it.

---

Another way you may use the abstract function method – is write then into an interface

package com.strangemother.database.engines
{
    import com.strangemother.database.Model;
    import com.strangemother.database.ModelSchema;
    import com.strangemother.database.events.ModelEvent;

    public interface IEngine
    {
        /**
         * Reads modelSchema and calls generateModel upon
         * each model found.
         * */
        function generateModelSchema(modelSchema:ModelSchema=null):String

        /**
         * Generate your CREATE syntax model to output to your SQL
         * 
         * If you are extending the framework with your own database
         * engine, you must override this with your own model generation
         * format.
         * */
        function generateModel(model:Model):String

    }
}

then at any point to use this, you implement it at class level

public class SQLite3 extends EngineBase implements IEngine
{

now my SQLite3 class must have the methods defined in IEngine

---

I much prefer to write classes with defined functions of which are overridden when implemented.

AbstractBase.as

/**
         * connect to the database. This is not usually
         * required as the abstraction layer should
         * automatically connect when required.
         * */
        public function connect(onComplete:Function=null):void
        {

SQLite3 of which extends AbstractionBase at some point

overide public function connect(onComplete:Function=null):void

---

Now to refute @Allan’s comment of it being less developed (Sorry dude)

No operator overloading – thats correct but neither does Java. it wasn’t applied to ensure AS3 was readable.

function overloading – You can’t hard type it, but you can have function makeTea(...args) passing in as many or as little data as you wish. you’ve also got getters/setters.

for inline functions you can create anonymous functions.

var myFunction:Function = Function(name:String):String{ return name + ' - rocks!'; }

You’ve got dynamic classes therefore class level overloading –

---

and good example of real code is Flex Lib – it open source and you can read read how all these elements are managed by glacing through the code.