>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 ;-)

From the "classical OOP" POV (as seen from java for instance) adding *implemetation* specific things is quite ok, but that should be done as "protected" as these internals are not part of the interface. My take on abstract classes is that they grew half-automatically from the rule that each method of an interface must be specified/implemented - so what good would it have to fill methods in the class specifying the interface ? I have read somewhere that Anders Hejlsberg wants to add a mechanism for "default method implementation" in interfaces - so there you have *somebody* <bg> not seeing the need for empty classes even in C#.

regards

thomas