Abstract functions in child classes

Adam Adam at Anizi.com
Fri Dec 2 09:10:33 PST 2011


Ok, let me give a more *specific* case of why this is a problem.

Suppose we have our Parent and Child cases from before

Parent exists in Library A
Child exists in my library, B
Library C, used by some developer, uses my library, B.

My Child is not meant to be abstract - it's intended to me
instantiable, and I document it as such. My documentation might even
include examples of construction.

I override all abstract methods of Parent.

Users of my library use instances of Child regularly.

Now, one day, the maintainer of Parent adds a new abstract function
to Parent. Please don't contest that this could happen - I see it
regularly in every language and every model of maintenance in real-
world development. Sometimes those interface developers are just
sadists.

Now, my library still compiles.

But, suddenly, users of my library are seeing errors on trying to
instantiate.

So what do I have to do to prevent this? I have to *explicitly*
check that Child is or is not instantiable, probably via unittest.
The alternative is that I must check over and read for every change
to the Parent library, even though the only reason I need to be
looking for new abstract functions is the exact same reason I'd need
to explicitly check that something is instantiable.


More information about the Digitalmars-d-learn mailing list