Virtual Methods and Brittle Base Classes

re: Virtual Methods and Brittle Base Classes

Dmitriy Zaslavskiy — Thu, 08 Jan 2004 15:45:00 GMT

Welcome back.

re: Virtual Methods and Brittle Base Classes

Eric Lippert — Thu, 08 Jan 2004 20:59:00 GMT

Thanks! It's good to be back!

re: Virtual Methods and Brittle Base Classes

Dan Shappir — Sun, 11 Jan 2004 22:06:00 GMT

For years the brittle base class problem had been used as a justification for why COM (and thus also VB) lacked implementation inheritance. I recall reading a whole exposition by Kraig Brockschmidt as to why implementation inheritance is not really required for OOP (and BTW, I agree with him.)

But then Microsoft got Java-envy and thus .NET not only supports implementation inheritance but makes significant use of it as a means for accessing system functionality. That is, it has effectively cemented the brittle base class problem into the OS. I could also argue that if implementation inheritance is such a good thing, C++-style multiple inheritance should also be supported.

Another point is that many programmers mistakenly believe that implementation inheritance is key for achieving code reuse in OOP. This is simply incorrect. While some code reuse can be achieved this way, most is achieved by having old code call new code through interfaces. For that you only need interfaces 'inheritance'.

Security and Inheritance

Office Development, Security, Randomness... — Thu, 15 Jan 2004 13:23:00 GMT

re: Virtual Methods and Brittle Base Classes

Eric Lippert — Thu, 15 Jan 2004 22:30:00 GMT

There are lots of ways to achieve code reuse, and inheritance is just one of them.

There are two main reasons that I see why people make class hierarchies. The first is to express "is a" relationships and hence achieve polymorphism. It doesn't matter whether classes Giraffe, Ungulate, Mammal and Animal share so much as a single line of code. What matters is that a Giraffe IS AN Ungulate IS A Mammal... and so we have a class hierarchy.

Now, that's all well and good, but most developers are extremely pragmatic. Most developers look at inheritance and say "is-a-shmiz-a, I need to use a Gadget but I also need to associate each with a Frob, let's see, I suppose I could write a hash table mapping Gadgets to Frobs, oh, to heck with that, I'm subclassing Gadget to create FrobberGadget, add a public field, OK, I'm done."

Not a very "purist" way to develop, but hey, that's the world we live in.

re: Virtual Methods and Brittle Base Classes

Dan Shappir — Fri, 16 Jan 2004 20:30:00 GMT

Developers will be developers, so I agree with your logic. But in my experience, if the developer has access to the Gadget source code, he'll just add the extra field to the original class, never mind that it's usually not needed and has nothing to do with the Gadget definition.

OTOH if the developer does not have access to the Gadget source, or is not allowed to modify it, it becomes an issue of whether or not the class can even be subclassed. Does it even have virtual functions? Also, there is the issue of recreating all the constructors. Bottom line, creating FrobberGadget may be more trouble than it's worth, even for a hacker.

My experience has been that most developers underuse implementation inheritance rather than overuse it.

Why Are So Many Of The Framework Classes Sealed?

Fabulous Adventures In Coding — Thu, 22 Jan 2004 23:45:00 GMT

Why Are So Many Of The Framework Classes Sealed?

Fabulous Adventures In Coding — Fri, 23 Jan 2004 00:01:00 GMT

Why Are So Many Of The Framework Classes Sealed?

Nazul's Weblog — Mon, 26 Jan 2004 06:49:00 GMT

Why Are So Many Of The Framework Classes Sealed?

Nazul's Weblog — Mon, 26 Jan 2004 06:49:00 GMT