Sorry for the length.
Abstract classes allow defined functions to exist, so that a function which is shared from more than one class doesn't have to be rewritten. (This is called factoring or refactoring, depending in which order it's done.
) It also allows for the programmer to devise an Interface to subsequent subclasses without having to write all the possibilities right now. Once the interface is designed, a programmer can ignore the very specific case, instead ordering the generic case to do something. For instance:
I suppose a case could be made that an Abstract class can be factored into an interface (for all abstract methods) and a defined class (for all defined, shared methods and properties) since an Interface is just an Abstract class which cannot have defined methods. But breaking them up has an added disadvantage of having two objects which relate to a single concept, instead of one: a super class which must be extended on to be of real use.
Since the above demonstration was not very descriptive, I'll post some code from my game engine.
In the engine, I then don't have to worry about what the file type is. Everything can be accessed from LayerImage, even though I can't make a LayerImage.
[ February 09, 2006: Message edited by: Jeremy Tartaglia ]