abstract classes are classes, that in themself make no sense, are incomplete, but an abstract of classes that will be derived from them. If you can use the abstract classes you planned not to used, they may not be that abstract, but simply the simplest form in which they are already usable...

I won't need to tell you, but several others seem not to know patterns... So for everybody wondering what that's good for: a simple example may be an abstract class being a class "vehicle", which has some things defined for all kinds of vehicles, while your application will only work with concrete vehicles, eg cars, trucks, trains, busses, etc. and not the abstract idea of a vehicle.

For a start: It's easy to prevent a classes creation by:

IF THIS.Class = "the abstract class name"
   MESSAGEBOX("It's not only useless but also impossible to instanciate this ("+THIS.Class+")!")
   RETURN .F.
ENDIF

What you can't prevent is, that this is overloaded and no DODEFAULT() is made from a subclass of this abstract class. But then it's not an abstract class anymore. If you have several levels of abstract classes, then it also doesn't matter, as it's sufficient to have it working for that concrete abstract class level ;-).

With a naming convention like _ as the class's last char you can use

RETURN NOT(Right(THIS.Class,1) == "_")

It will not break any concrete class to work, even if it does DODEFAULT(). As THIS.Class is always the name of the instanciated class, even in code that is inherited.

It will not prevent you putting an object of such a class on a form at design time, since the designer "instanciates" objects without running the init. But at runtime those objects will vanish from the form as if you never put them there...

As a real world case I use this for a family of classes that make up a databasse interface as some kind of service oriented structure to allow access to a database for several applications, each using their own set of methods that have a common core, but even those common methods have different results, depending on what those applications need, sometimes only differing in the names of the result cursors fields to match the naming convention of the using application. There is a level of abstract classes nobody is supposed to use, they should instanciate their concrete database interface only.

Another real world case I work on is an abstract class handling a type of record that exisits in several abstractions or concretisations if you want to put it the other side around. It's complicated to explain, but an easy example is you have product types and products. product types are abstract, a product is concrete.

Bye, Olaf.