Class Design Deviations from Java to ActionScript

Question

I mainly work in Java, but I recently started using ActionScript 3.0 for a multi-player Flash game that I am helping to develop. The project is in its early stages, so I'm still working on the structure of the class. I continue to run into limitations in the ActionScript language when I try to use many of the OOP features that I expect in Java.

For instance:

• I need an abstract Character class. There is no reason why Character was ever created, but ActionScript does not support abstract classes. As a result, my code has this comment at the top:

Character must be an abstract class, but AS does not support abstract classes.

DO NOT CREATE AN INSTANCE OF THIS CLASS. (Only an instance of classes that extend this (e.g., Player, Zombies))

• As a result of designing Flixel (the library used), I need to have a CharacterGroup class with an internal Character class, so that a CharacterGroup can also contain other sprites, such as weapons and so on. In Java, I would use an inner class. ActionScript does not 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 less developed, or do I find ActionScript so frustrating that I try to write it as if it were Java, rather than working on how ActionScript was designed?

In other words, is the “right” way to create an OO design different in ActionScript than in Java?

(Note: I am not asking for an opinion on why ActionScript is better / worse than Java. I only ask if I am coding correctly or trying to learn too much from my experience with Java.)

Thanks!

Answer 1

AS3 does not miss a function, and you cannot define it as "less developed."

Firstly, for your problem - there are ways related to the methodology of the abstract class. For your abstract Character class - you can make the user developer get an error when trying to create an instance.

 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 should be used by the ".getInstance" method, but to extend this, only this class can create a new instance of itself, since its the only class that can see the inner class SingletonLock {} ". For your purpose, you can remove the getInstance () method and force another way to get an instance of this class.

This should also reflect the ability to create inner classes. They cannot be noticed by any other class - only this package and the parent class CentralDispatch can use it.

---

Another way to use the abstract function method is to then write to 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 time to use this, you implement it at the class level

 public class SQLite3 extends EngineBase implements IEngine { 

now my SQLite3 class should have methods defined in IEngine

---

I prefer to write classes with specific functions that are overridden during implementation.

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 from which extends AbstractionBase at some point

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

---

Now refute @Allan's comment that it is less developed (sorry, dude)

No operator overloading - this is correct, but not Java. It has not been used to ensure readability of AS3.

Function overloading - you cannot type it hard, but you can have function makeTea(...args) , passing as much or as little data as possible. you also have getters / setters.

for built-in functions, you can create anonymous functions.

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

You have dynamic classes, so class level overloading is

---

and a good example of real code is Flex Lib, which is open source, and you can read how all these elements are controlled by flashing through the code.

Answer 2

This is somewhat subjective, but I personally would say that the "right" way to create OO design in AS3 is the same as Java, and yes AS3 is less developed.

AS2 was a very prototype similar to JavaScript, although, as with JavaScript, you can still program it in a classic style. Then AS3, which was based on the ECMAScript edition 4 project, followed. An upgrade to ECMAScript made it more classic, similar to Java (JavaScript 2, which was supposed to be based on it, but was dropped as members of the committee in question, has changed too much). Thus, although AS3 is now a more classic Java-style language, as you have learned, it illuminates the language’s capabilities. At the top of my head there are no such things as:

• operator overload
• function overload
• generics
• abstract classes
• built-in functions
• inner classes that you pointed to

and probably a lot more things that other languages ​​have that I don’t know about. It’s clear that it’s annoying not to use the language features that you’re used to, but most of the time I came to find out that the missing things are a luxury *. You can do without them, this can lead to your code becoming a little more dangerous and verbose, and this is just what you must learn to live.

There are several hack methods to try to mimic some of these features, but I rarely worry.

* You can also try looking at the HaXe language . The code compiles in LLVM to ABC bytecode. HaXe supports generics, built-in functions, conditional compilation (and much more). I use it whenever I write a library.