>>>>Hi Peter,
>>>>
>>>>abstract classes are necessary to define the pure interface for your concrete classes. This way you can react to language- and property modifications. From VFP9 point of view this might not be necessary anymore, as there won't be any changes coming by MS, but for me that's no reason to change my behaviour.
>>>
>>>I can imagine that at least one child from a base class is 'necessary' or at least useful. But if that child contains ALL that you need in a part of the application (apart from what must be set in the instance itself) then why declare it abstract?
>>>
>>
>>i.e. before VFP had the anchor-property we had created this property within out framework by default. With VFP introduction to this, we ran into an error as there was already a property called 'anchor' within VFPs baseclass.
>>So all we had to do, was renaming our property and changing the corresponding code snipets.
>
>But this is not a problem that can only be solved in an abstract class. And it can also occur in a concrete class. Adding properties and methods is also done in conctrete classes.

IMHO it depends on how you work with classes. Our approach works fine for us. Interface design within the abstract class. Coding within the concrete Class. Abstract classes in myAbstractClasslib.vcx, coding in myConcreteClasslib.vcx.

However, you've got a point that adding props and method is often done in concrete classes. Well, if the programmer can live with it... In small projects, mostly prototyping, that have to be done quick and dirty, I still work that way. But usually I like the splitted approach a whole lot more. I know where I have to look for in my projects and my co-worker too ;-)