Question

Fragile base class is one of the most common point that gets popped up in every discussion where reusability through implementation inheritance is discussed.

Has anyone faced any real issue with these apart from the common square, rectangle examples.

Everytime I need to explain this to someone I am stuck with some real world cases where these problems aroused and how this was solved.

If anyone would like to share their experience regarding this it would be really helpful.

Here’s a wikipedia link to understand this problem

Fragile base class on wikipedia

EDIT:

My inputs with respect to this… The problem mostly happens when the base class version changes as the developers using this may not be aware of the extensions happening to the base class implementation and the base class implementor may not have all the necessary details about all the derived classes. And the seemingly innocuous change may break all the derived class functionality. And in any case this is a bad design practice as it will break the OCP principle.

Got a nice quote from Joel on Software old forum. Thought of putting it down.

‘Our inability to sometimes deal with the complexities of modern life is actually an example of the fragile base class problem occurring in nature, the reason being that we’re still inheriting many characteristics from our ancestors who led very different lives.’

Answer 1

Yes – java.util.Properties is a pain to derive from.

For the moment let’s leave aside the fact that it derives from java.util.Hashtable to start with (which means it has get(Object) and put(Object, Object) despite the fact that properties are always strings…

I once subclassed java.util.Properties to provide a sort of hierarchical structure – in a properties file I had:

x.y.z = 10 a.b.c = 10 

and you could ask the ‘master’ properties for ‘x’ (with a new method call) and it would give you another properties object which would effectively contain ‘y.z = 10’ etc. It was handy to subclass java.util.Properties as many other pieces of code already knew used properties. If it had implemented an interface, I wouldn’t have subclassed, and I wouldn’t have had any problems 🙁

Anyway, I needed to override getProperty() to refer back to the parent properties if necessary. But there are two overloads – which should I override? Does getProperty(String) call getProperty(String,String) or vice versa? Maybe I only need to override get()? It’s not documented, and if I only overrode one of them, the implementation could change in a later version to switch things round – so I needed to override both of them.

The same went for various other methods (saving and loading were a pain, IIRC – this was a long time ago). Basically I could have done the job more simply if I could have relied on bits of the implementation of Properties not changing – but that would obviously have made it harder for Sun to improve the implementation at a later date.

Anyway, this was a definite example where composition and exposing an interface which clients would rely on would have been much better.