[ad#ad_content]ActionScript developers are a poor bunch! Internet Applications have become more and more complex and require you to plan your architecture carefully. In fact you need to be not only a programmer but also a full-fledged OOP architect if you want to achieve complex applications or otherwise two weeks later when the client asks for changes you will be in code chaos hell. On the other side the customer can’t care less and asks you to finish their product within two weeks just like it was in the old days of  Flash 5 where you could churn out some wonders quickly (but dirty under the hood) because, hey, does the client care how well your code is organized? The hell he cares! I feel kind of like: first we all yelled for better code management, now that we have it people start to complain that it’s too OOP.

Being a game developer who has a few more ambitious projects on the shelf I’m all for OOP and coding-best-practices. The artsy-fartsy Flash Designer hype from yesteryear had it’s show but now please move along, it’s time to advance!  Personally ActionScript was what has taught me OOP practices and I would be nowhere today if it wasn’t for ActionScript. Sure, I could have probably learned it from C++ or Java too but ActionScript’s prevalent support and documentation made it a lot easier.

I’m all for strict typing and seeing some people wishing back dynamic typed features makes my stomach turn over. Instead I’d rather like to see more data structures that allow strong typing just like the recently introduced Vector does. Really, there’s no way that 10 horses can pull me back to dynamic typed programming! Sometimes I find AS3 code examples on the web which are all untyped and dynamic, obviously by some coder who completely neglected strong typing because he either didn’t fully understood it or was too lazy. This is what Nicolas Canasse got right when he stated that ActionScript lacks expressiveness. It leads to people falling back to dynamic typing if they see that all this extra stuff required for the correct approach. I use FDT which has an excellent template system so I don’t really care if there’s a tad more code to write to achieve good code. In fact OOP stipulates more code. At first I worried too but I’ve learned to live with that.

I think Adobe should loosen the grip of ECMA 4 on ActionScript which it already has broken anyway by not being fully compatible to it anymore. haXe is doing many things right where Adobe fails with ActionScript, advanced OOP features like Generics, typed Arrays with auto-casting, in-lining, Enums etc. To stay up to competition ActionScript needs these and then some. Others have already listed their feature hopes which I reflect but here are they once more:

• Method Overloading (because writing Open-Source frameworks and libraries often is a travesty without this).
• Generics
• Threading (Oh yes!)
• Multi-CPU-Support
• Private Constructors (bring them back!)
• True Abstract classes/methods
• Enums (has been a long time wish. Don’t know what the problem is!)
• Hardware rendering (PV3D etc. are great and all but whats the point if you hit the wall with under 1000 triangles?!)
• Compiler performance (Seriously MXMLC needs to hide in the corner if the haXe compiler shows up!)
• And last but not least I’d like to see a lot more love for the AIR runtime like better OS-integration (changing screen resolution for example) and better performance and resource management (the way how AIR wastes up RAM is not from this planet!)

It seems that many newcomers to ActionScript still don’t understand the use of ‘this’ and that it’s only really necessary in rare cases, for example if a method parameter has the same name like it’s relative class property or in a few scope-related situations. It’s also good to have ‘this’ at hand if a dynamic property of a class needs to be accessed (this["foo"]) but other than that please do all a favor and throw out those unnecessary ‘this’! Ban it, lock it in your basement and don’t let it out unless there’s really a need for it!

override public function toString():String {
	return "[ClassName]";
}

… Sometimes adding properties to the returned String that give back information about the class, e.g.

override public function toString():String {
	return "[ImageClass, size=" + _size + "]";
}

But writing them rigid like that is a disadvantage when you decide later to refactor class names. Admittedly it’s also not a very elegant way so I got the idea to take the class name that is returned by getQualifiedClassName(). The only problem is that getQualifiedClassName not only provides the type name but also the whole package String of the class. Regular Expressions to the rescue! After twiddling around with them for a while (I’m by no means a RegExp expert) I got my toString method into the shape that I desired:

override public function toString():String {
	return "[" + getQualifiedClassName(this).match("[^:]*$")[0] + ", size=" + _size + "]";
}

This way it matches the String returned by getQualifiedClassName with the Regular Expression [^:]*$ which checks from the right end for an arbitrary text up to the first occurring colon, but without including the colon. Taking the first element of the Array returned by match() and you got what you need!

A nice way of using this is when writing abstract classes that contain the toString method and any subclass can use that toString method without the need to override it … that is of course unless you want ot add other output information.

[ad#ad_content]So how good is this book? If you are familiar with ActionScript 2 or 3 this is a good book which is easy to understand and to follow most time. If you’re rather new to AS it might be more difficult, not only because of the difficulty to understand OOP but also because many of the code listings in the book have errors. Somebody who is experienced with ActionScript will usually notice the mistakes and correct them while typing but somebody without enough knowledge will probably curse about why the examples per se don’t run.
Many of the Pattern lessons go into deeper detail than other Pattern books I’ve read which is a plus! For example in the Command Pattern they not just tell that this Pattern can be used to code Undo/Redo functionality, it also shows how to do so. On the other hand some of the code listing are a bit boring. Who wants to type that dull clock application again for learning the MVC pattern?! I think I saw it before in EAS2.0. But it might be just me waiting for the day where such books are tailored for Game Programmers!
Personally I would have welcome it if the design process stuff had received more attention by being more deep and for example explaining sequence diagrams.
During the code examples some classes are utilized that are part of the book and can be downloaded on the web, or let’s say they could be downloaded if the book’s code site were available already.
Apart from these small slips (from which the code incorrectness weights most IMO) I would say this is a decent book that has the ability to teach Patterns where other books were either too advanced or too simple for this topic.

[ad#ad_content]This has changed instantly today when I read a sample eBook chapter of Joey Lott’s Advanced ActionScript 3 with Design Patterns on Adobe Labs new Digital Editions Service , a book that I actually ordered already a couple of days ago (takes a bit to ship to Japan though).

What can I say? This small chapter explains it extremely easy and logically. I’ve read EAS 2.0 and Head First but this sample chapter made me getting it for the first time really! It also explains about the difference of Abstract Classes and Interfaces, something that has not been mentioned in any other ActionScript book I’ve read so far.
Full respect to the author! If the rest of the book is of similar quality and clarity I shall be damned if I will not be an OOP Pattern Master in near future!

On a side note, the sample books are being downloaded of what looks like an Apollo app. I’m not sure how far this is related to Apollo but it works like a standalone eBook reader is downloaded and installed and sample chapters open in it.