>... But in the real application I also started to use the so-called abstract class where I needed no special methods or properties.

per my other post about thoughts on the abstract savebutton it's already concrete if it's put on a form. As soon as the form is not concrete it would nevertheless not instanciate and that would be sufficient. As soon as the abstract form with that abstract button (or editbox) is subclassed as a concrete form, you'd already make it a concrete button or editbox.

Why should a class only become concrete in a direct subclassing?

>So indeed, rather than being an abstract class, that editbox is more a simple class.
I wouldn't define it that way.

abstract also does not need to be incomplete in that way that it does not work without additional code or dependant other classes. It's abstract, because it's a general idea of the real thing, like a product type is the idea of some range of poducts. The only difference this time is, the abstract editbox is already an editbox. Sometimes you can't abstract it more than the most simple way you actually will use it. And there is no reason you should for example make the abstract editbox, then subclass it and only change the font in that concrete subclass. I think that's not a serious, but a ridiculous interpretation of what is an abstract class.

You already have that additional layer of the editbox class additional to the editbox baseclass and therefore have a way to change all concrete editboxes by changing this class, which is sufficient enough in my opinion.

>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! :)

LOL

Bye, Olaf.