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

That's indeed what has been the case. As an example, for a certain application I created an editbox and declared it abstract, using NewClass.app. (NewClass will add an underscore to the right of the name and it will also put the text '[Abstract class]' in the description that's shown in the Project Manager.) Then I changed the fontname and that was it. Later on several other, indeed concrete, classes were based on it. But in the real application I also started to use the so-called abstract class where I needed no special methods or properties.

So indeed, rather than being an abstract class, that editbox is more a simple class. I should not have declared it as an abstract class. There was no argument to do so because there were still no methods or properties that need to be filled or set. And there was also no dependency on other classes.

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

The NewClass.app allows the character to be redefined, but the default is indeed the underscore.

Come to think of it... What's perhaps a typical characteristic of an abstract class is that it cannot be well used without instructions. Added methods are likely still empty and must be filled with code, properties must still be set to values and other classes that it depends upon must be used too. An instruction (a manual or documentation) is required to implement the abstract class.

Instead of only returning False in case this.class ends with an underscore, the class might display its documentation or a link to that documentation, before returning False in the init.

There's another issue now coming to mind. If 'incompleteness' is indeed the main characteristic of an abstract class and if concrete classes should not have incompleteness at all, it must be admitted by me that I have declared many classes as concrete where they should have been declared as abstract!

OOPs! :)