I cannot thank you enough for that example! Virtually all of the best examples of design patterns seem to come from Java, but like Small Talk, Java has abstract classes as well as other features not found in ActionScript. Those of us who come from ActionScript there’s a double frustration. If we do not know Java well, then it’s a bear to find a workaround. If we do know Java well, as is your case, we’re frustrated by what Java has and ActionScript does not.

However, in all fairness to both ActionScript and the engineers at Adobe, ActionScript is faithful to the ECMA 262 r4 standards. I’ve heard some scuttlebutt that ECMA may deign to change that feature for 262. ECMAScript 334 [C#] does have abstract classes, and I have no idea why it does and we don’t, unless it has something to do with JavaScript.

Thanks again,
Bill

interface IDrawable
– defines draw()

class AbstractDrawable implements IDrawable
– defines properties of the drawable such as color
– must implement draw() in ActionScript

class CircleDrawable
– must override draw() in ActionScript

class RectangleDrawable
– must override draw() in ActionScript

In Java this is great because it ensures that my derived classes implement all of the methods of IDrawable (there is no draw() method defined in AbstractDrawable in the Java implementation).

This can technically be achieved by making your derived classes implement the interface and removing it from the abstract class. However, it leads to an assumption of what the abstract defines, breaking encapsulation.

As a complete aside, I also find it interesting that the “virtual” keyword is a valid modifier for a method but doesn’t seem to change the behavior. I’m curious if there’s any relation between its presence, lack of its implementation, and the lack of abstract classes.

What I’ve come around to with ActionScript abstract classes is to treat them as interfaces. I’m not sure which design patterns derive abstract classes from interfaces, but when I see interface, I assume that it can be either an abstract class or an interface (using the keyword interface). In Part IV of the series on Take a Design Pattern to Work, the two interfaces I use (Creator and Product) are in fact abstract classes both in the sense that they are not instantiated and that they include methods that must be overridden.

I don’t know if that’s a helpful way to deal with the ActionScript version of an abstract class or not, but it’s been useful for me.

Thanks again for your comment,
Bill

ActionScript, however, forces you to implement every method in the interface because of the lack of abstract classes. Now every derived class must override every method in the interface, regardless of whether or not they’ve truly been implemented. Just about every method in my derived class is marked as override, and the keyword has lost any value to me as a programmer.

Furthermore, you have to keep moving back and forth between the interface, the abstract class, and the derived class to see what you need to implement. Ideally, I just get a compile error telling me which methods in the interface have not been implemented by either the abstract class or the derived class.

Your point gets back to a seamless design pattern mindset. I believe we are able to do things quickly when doing them wrong because those who followed the ActionScript path from 1 to 3 were first given a “wrong” way to develop a program that didn’t have either large sets of code embedded in classes or flexible long range development for re-use and re-factoring.

As for occasionally using override, I’m assuming you’re referring to abstract classes. But are you always using override when you have an abstract class (one that begins with an ‘a’ in your case) or do you only sometimes use override with classes that are extended but not instantiated? In other words, are some of your abstract classes of the Forrest Gump variety?

Thanks,
Bill

I really like the idea of sticking with the ECMAScript 262 E4 standards, and as far as I know, ECMA would be the place to petition. The main advantage of staying with the standard is to reduce the possibility of a lot of “improved” AS3 versions popping up leading us back to the bad old days when every program seemed to need a special patch or plugin for someone’s idea of improvement.

Anyway, you may have answered the real query–the “half-abstract” nature of an abstract class. The Template Method is a good example of how an abstract class should function because only part of it is concrete. So rather than the Forrest Gump definition, we need at least part of it to be overridden by the child classes. That might be a useful characterization of an AS3 abstract class.

Thanks for your thoughts on this,
Bill

All I can say is that it would cost Adobe next to nothing to implement the tiny “abstract” keyword. For a subclass, extending an abstract class would be just like extending a regular class and implementing an interface, because an abstract class is just that: half concrete and half abstract. Where should we petition for this? It’s so simple, and yet we still don’t have it :-/

However yes, I do occasionally use override for different purposes. Quite often it is the result of sloppy coding, but in the real world I regrettably don’t have the time to write beautiful things. “I want it done by yesterday” isn’t half as bad as “Say, you know what? I like the project, just please save it as AS2 instead of AS3 and put it on the server” – especially when it’s 50 or co AS3 classes. Gotta love management.

Thanks for you comment. I guess I didn’t phrase it very well, but the issue is not over the lack of an abstract modifier statement so much as it is if a parent class is treated as an abstract class whether it really works as one. For example, suppose your AbstractButton class has everything all set for creating buttons, and the child classes simply extend it but do not instantiate it. What if none of the functions are overridden because they do not need to be?

In the example you have, the parent class has a constructor function, which is fine. However, in cases where a constructor function is unnecessary, and the child classes extend the AbstractButton will they then be part of an interface pivoted on the abstract class?

By the way, if you didn’t see Chandima’s post on abstract classes, you might find it helpful.

Thanks,
Bill