Abstract is as Abstract Does: A Forrest Gump Approach to Abstract Classes in ActionScript 3.0

15 Responses to “Abstract is as Abstract Does: A Forrest Gump Approach to Abstract Classes in ActionScript 3.0”

• Nate Beck

  January 11, 2009 at 2:19 pm

  I completely agree with you in this post. I’ve been following these discussions for years now, and I have no clue why abstract wasn’t included in ActionScript 3.0.

  I pretty much have been getting around the lack of abstract classes by using a common practice (in C#) of including the word “abstract” in the class name. Example, AbstractStaff.

  Also, if I’m not planning on other developers using my abstract classes, I use the [ExcludeClass] metadata tag to hide the abstract class from the IDE.

  Adobe seems to do the same thing with some “abstract” classes in their library.
• Daniel

  January 11, 2009 at 3:38 pm

  Simply put: No.
• Bill Sanders

  January 11, 2009 at 5:53 pm

  C’mon Daniel provide a little context. We assume all of our readers are literate, and your comment, while to the point, does not provide anything useful.

  That’s about as helpful as those (shudder) ‘nuf said comments. It is not enough, and I believe you have a reason to make an intelligent comment. This post was set up to be a discussion, not a poll. Please say a little more. While brevity is the soul of wit, monosyllabalic grunts are not.

  So why not start with something, like, “Bill, you’re as dumb as a bag of hammers…” and then go on to explain yourself. This is supposed to be a conversation.

  Thanks,
  Bill
• Bill Sanders

  January 11, 2009 at 6:05 pm

  Hi Nate,

  Thanks for your comments. I almost hated to bring up the subject because (1) Abstract modifiers are not part of the ECMAScript 262 r4 standards, and (2) there have been so many posts on abstract classes in ActionScript–including the excellent one Chandima did to which I made a reference.

  The focus has been on how to make sure that abstract classes are not instantiated, but I was hoping to look at them in the larger context of doing design patterns–especially in the role of helpful interfaces.

  Kindest regards,
  Bill
• Matt

  January 12, 2009 at 12:49 pm

  Honestly, I don’t understand all the fuss when it comes to AS3’s lack of abstract modifiers. In my own work I’ve created a set of abstract classes to help quicken my own development. For instance I have my handy dandy AbstractButton class that has all basic button functionality built into it. I can simply extend it and override any of the documented methods to give my custom button the behavior I desire. This approach works great for me because I know what an abstract class is meant to do and don’t need compile time errors to tell me that I’m doing something wrong. I’m smart enough to know that I should never create an instance of an abstract class. In the case that other developers use my asbtract classes I’ve done one thing that should prevent that class from being instantiated on its own. I can’t remember where I picked this up, but I remember seeing on some other blog. The technique is to require one parameter in the constructor of the abstract that is of the abstract class type. For instance:

  ^?View Code ACTIONSCRIPT

  1 2 3 4 5 6 7

  public class AbstractButton { public function AbstractButton( self:AbstractButton ) { if( self != this ) throw new IllegalOperationError( "..." ); } }

  So in the constructor of any class that extends AbstractButton I simply put a super( this ); statement in it. Its a bit annoying to have to do, and not totally foolproof, but it seems to me to be the easiest thing to do to give your abstract classes a bit of rules.
• Bill Sanders

  January 12, 2009 at 2:48 pm

  Hi Matt,

  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
• archont

  January 12, 2009 at 4:36 pm

  I have a habit of prefixing concrete classes with c and abstract classes with a.

  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.
• TK

  January 12, 2009 at 5:34 pm

  Among other things, the abstract keyword is what we’re really lacking. I’m working on something of a solution to this, but I can’t be any more specific than that :)

  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 :-/
• Bill Sanders

  January 12, 2009 at 6:54 pm

  Hi TK,

  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
• Bill Sanders

  January 13, 2009 at 2:30 am

  Hi Archont,

  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
• Dale Beermann

  January 15, 2009 at 11:18 am

  I’ve been frustrated by the lack of abstract classes for a lot of reasons. More often than not though, I have an abstract class that implements a particular interface. Yet, I don’t want to define the functionality for that entire interface in the abstract class.

  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.
• Bill Sanders

  January 15, 2009 at 2:05 pm

  Hi Dale,

  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
• Dale Beermann

  January 15, 2009 at 2:45 pm

  Our issue stems partially from porting from Java to Flash but I think could come up when starting in ActionScript as well. Here’s an example of a design pattern where the interface is implemented in the abstract class:

  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.
• Bill Sanders

  January 15, 2009 at 3:03 pm

  Hi Dale,

  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
• Dale Beermann

  January 15, 2009 at 3:30 pm

  Glad that made sense :) I forget that some people may not have used languages that are a bit more “true” to OOP. We’ve come across a lot of things like this actually. Personally, I think that, for the reasons I stated above, the lack of abstract classes leads to poor programming practices because you have to bend some of the fundamental rules of OOP in order to do what you want.