Comments on: More on Abstract Classes in AS3

By: Abstract Classes in AS3 at AlecMcE.com

Abstract Classes in AS3 at AlecMcE.com — Wed, 29 Jul 2009 13:04:42 +0000

[...] a new library at work, we were pondering what was the best strategy for abstract classes. Despite arguments to the contrary, we respectfully believe that abstract classes are useful! A quick Google search produces a lot of [...]

By: kp

kp — Sat, 14 Feb 2009 15:22:33 +0000

no problem at all Nick. I’m glad to have ideas shared. Also added your feed to my netvibes, Looks like you have some interesting stuff there.

By: Nick Wiggill

Nick Wiggill — Sat, 14 Feb 2009 15:12:08 +0000

Oh and a little more…

@Keith, I couldn’t agree more, really. Eliminating derived class cruft is a worthy goal but sometimes (particularly when you doing “evolutionary” development as is the Agile way), it is very difficult to *know* what to shift up to a base/abstract class, and what to keep in the derived classes, until you’ve actually used the thing a bit and it starts to show the form it wants to take, if you can excuse the anthropomorphism.

@Mike Welsh post — In regards to the rest of your post (which I didn’t read fully the first time!) I completely agree, having implemented an MVC game framework in that way myself. It is without doubt the cleanest method, if and when you are able to take the time on it. Sadly, the DisplayObject paradigm in ActionScript confuses a lot of developers in terms of separating controller logic from display logic, and for starting game developers this is really a bad thing if they plan to move onto bigger and better things than Flash games.

Thanks to all for some

By: Nick Wiggill

Nick Wiggill — Sat, 14 Feb 2009 14:48:47 +0000

In response to what Mike Welsh said (and probably of interest to other game devs reading these comments), I don’t I entirely agree, and I think that’s rather a broad and sweeping statement. The example you’ve given makes sense, but a game object can be a lot of different things. There are implementations (like one I’m working on right now) where a game object can be a lot of different things (“has-a” vs “is-a”) at once. For example think of a racing game where you have all sorts of different cars made up of different components that you have bought. This car is assembled from these components (even if not in the more physical sense), eg. it has a particular type of gearbox, particular spoilers, mags, tyres, engine, supercharger etc. There are far too many possible permutations here to predict, thus inheritance is out the window for this type of scenario.

Here is a post on my blog discussing the matter of composition in game frameworks: http://www.visualharmonics.co.uk/actionscript-3/using-function-closures-in-object-composition/

(Hope you don’t mind Keith)

Regards,

-Nick

By: Cotton

Cotton — Tue, 27 May 2008 05:54:47 +0000

Good news! I find out this in bugs.adobe.com, it seems the SDK team already working on it

To support full OOP: Abstract method [Status:Open ]
https://bugs.adobe.com/jira/browse/ASC-3379

By: ekameleon

ekameleon — Fri, 16 May 2008 07:17:51 +0000

Hello

For me … not need of abstract class for the moment in AS3

I prefere speak about “helper” class who implement one or more interfaces.

In VEGAS my framework opensource i use the “getInstance()” method like a “Factory” or a “Locator” method to returns one object singleton in my application. But i can continue to instanciate my class with the new keyword !

In other case, i use the “getInstance()” method with an argument ‘id’ or ‘name’ or ‘channel’… to returns “multi-singleton” objects of my class.

Example :


import flash.events.Event ;

import vegas.events.EventDispatcher ;
function testHandler1( e:Event ):void { trace("test1 : " + e) } ;

function testHandler2( e:Event ):void { trace("test2 : " + e) } ;
// register controllers in my application with multi FrontController singleton reference in my application (multi channel to dispatch the events in the global event flow)
FrontController.getInstance("channel1").insert( "test1" , testHandler1 ) ;
FrontController.getInstance("channel2").insert( "test2" , testHandler2 ) ;
// test - i dispatch the events in 2 channels in my application.
EventDispatcher.getInstance("channel1").dispatchEvent( new Event("test1") ) ;
EventDispatcher.getInstance("channel2").dispatchEvent( new Event("test2") ) ;

I can instanciate my 2 class with the new keyword too It’s not a problem

EKA+

By: Iain

Iain — Fri, 18 Apr 2008 22:03:55 +0000

Troy and Mike – thanks for the feedback, it’s good to know I’m on the right track with this. Where I use inheritance in complex games I end up having to dynamic cast alot, and also end up overriding half the code in my base classes, and it seems “messy”. Much better to divide the code into reusable “behavior” objects (memories of Director!). I’m thinking that my code should look something like this:

if (gameObject.movable)
gameObject.movable.move(5, 5);

One thing I’m not sure of – should I have a variable in my base class (initially set to null) for every possible behavior? Do I only need one base class?

Someone needs to write a tutorial about object composition / aggregation as it relates specifically to Flash (and esp. games). I’ve read a bit about this for C++ games but never for Flash games.

By: Troy Gilbert

Troy Gilbert — Fri, 18 Apr 2008 19:00:15 +0000

It’d be nice if AS3 had abstract classes, but largely for the same reasons it’d be nice if it had multiple inheritance: to save typing. Sometimes you want to create base class that holds functionality for a tree of classes but the base class doesn’t actually do everything it needs to do usefully (DisplayObject and DisplayObjectContainer are *excellent* examples of this). Same with multiple inheritance: I hate it when used a poor replacement for composition, but its a quick-n-easy way to get mix-in functionality.

In regards to games: composition is *way* more favorable to inheritance. In our new game making app, all game objects are decomposed into actions that are composited together. Technically, its implemented as a decorator pattern to make conflict resolution easier, but if the target audience was programmers it’d be a generic object composition framework. Flash’s native event system is *really* handy for these composition frameworks, to the point where I’ve experimented with have all behavioral components subclass Sprite and be literal children of their game object to automagically handle input event propogation, etc.

By: kp

kp — Fri, 18 Apr 2008 11:56:36 +0000

Ewan, I’m not saying they aren’t useful. Not saying they shouldn’t be there. But they aren’t there. And “useful” doesn’t mean “you couldn’t possibly do without them” or “ActionScript is not a ‘real’ OO language because it doesn’t have them”

By: Ewan

Ewan — Fri, 18 Apr 2008 00:02:01 +0000

Abstract classes are freaking useful. That’s why they exist in other programming languages – they should also exist in ActionScript.

The same goes for Singletons. Why is it that you could make a constructor private in AS2 but not AS3 – it’s nuts.