More on Abstract Classes in AS3
A while back I posted about Singletons and Abstract Classes in AS3. My basic argument was along the lines of “AS3 doesn’t support them, so chill out and stop trying to force them into existence.” I was probably went a bit too far in that direction. Although I completely disagree that Singletons are one of the “core patterns used in object-oriented programming” (more likely the core overused pattern that breaks object-oriented designs), they do have valid uses. So it’s nice if you are releasing a Singleton class to at least provide a readable error message that says, “Hey, you weren’t supposed to instantiate me. Use getInstance(), bud!”
On the other hand, we have abstract classes. One commenter said,
An OO language without abstract classes is barely an OO language at all. The proper way to think when developing an app OO style is to develop 70% of it in abstract classes, and the rest as instantiable classes. In other words, abstract classes aren’t an afterthought, they’re the thought.
This stuck with me for a while. There are parts of it that are true. You do want to code to interfaces, and abstract classes are an important part of that. On the other hand, leaping though over-engineered hoops to make “abstract” classes non-instantiable just seems stupid to me.
I’m currently reading Kent Beck’s Implementation Patterns
The superclass is abstract in the sense that it can be replaced at runtime with any subclass, whether it is abstract in the Java sense or not.
Further on he talks about “real” abstract classes:
Using the keyword abstract with a class tells readers that they will have to do some implementation work if they want to use the class. If there is any chance to make the root of a class hierarchy useful and instantiable on its own, do so. Once on the path of abstraction, it is easy to go too far and create abstractions that never pay off. Striving to make root classes instantiable encourages you to eliminate abstractions that are unlikely to pull their weight.
Yes, I agree completely. This is what I was getting at, or trying to. Of course you can create subclasses and code to them as interfaces in ActionScript. So what if those base classes are instantiable? The simple fact of them not being non-instantiable is not going to break your application. Sure, if someone creates an instance of an “abstract” class, or fails to implement an abstract method, it’s going to fall back to the base class and do nothing, or whatever default implementation you have. But even still, it shouldn’t break anything. Name it as abstract: AbstractFoo. Foo extends AbstractFoo. If you want to throw some errors in your abstract methods, go for it. If you really think you need it, throw an error in the constructor, as described in various places.
But keep it simple. My original point was not that these things aren’t occasionally needed in AS3, but that page after page and blog post after blog post and argument after argument about the best way to create an airtight, foolproof, perfect abstract class or private constructor was getting ridiculous. Take reasonable measures and get on with it.
And in fact, as Beck describes above, you should actually strive to make your base classes instantiable and eliminate useless abstractions. This is a far cry from “an OO language without abstract classes is barely an OO language at all.”
OK, now I will prepare for the onslaught of angry comments… 🙂