Here it is 2009, and the discussions about the lack of abstract classes in ActionScript 3.0 go back at least to 2006. Chandima’s 2007 post nicely deals with a number of issues concerning abstract classes, and I’m not going to try and improve on that. Instead, in this short post, I want to bring up two simple issues. Acting abstractly and what use is there for the override statement if not for abstract classes?
Abstract is as Abstract Does
In barreling along in my Take a Design Pattern to Work [Part III] series, one of the classes, Staff, works as a nice solution for creating lots of child classes with just a couple lines of code (the child has just a few lines, not the parent.) The Staff class is extended but not instantitated, just like an abstract class. Since we have no abstract modifier in ActionScript 3.0 anyway, what is the difference between a class we treat in exactly the same way as an abstract class as far as not instantiating it but only extending it and a real abstract class in the ActionScript 3.0 sense?
Override for What?
Maybe it’s me, but the only time I use the override statement is when I’m creating a function derived from an ersatz ActionScript 3.0 abstract class. So my question is, why give us an override statement but not give us an abstract class modifier? Does anyone use override for anything other than changing a function derived from a parent class so as to make the parent act like an abstract class?
Interfaces: Interface and Abstract Classes
When you look at the design patterns in GoF and elsewhere, the term interface can refer to either abstract classes or an interface—the interface statement in ActionScript 3.0. In design patterns interfaces are important because they aid in keeping participants loose but connected. Given the goal of looseness, does a Forrest Gump defined abstract class (extended but not instantiated) serve that goal?
Comments invited.
Bill Sanders
Recent Comments