Q:

Inheritance gone wrong

I have some code where a good inheritance model has gone downhill and I am trying to understand why and how to fix it. Basically, imagine you have a Zoo hierarchy with:
class Animal  
class Parrot : Animal 
class Elephant : Animal 
class Cow : Animal

etc. 
You have your eat(), run(), etc methods and all is good. Then one day someone comes along and says - our CageBuilder class works great and uses the animal.weight() and animal.height(), except for the new African Bison which is too strong and can shatter the wall, so I am gonna add one more property to the Animal class -- isAfricanBizon() and use that when choosing the material and only override it for the AfricanBizon class. Next person comes and does something similar and next thing you know you have all these properties specific for some subset of the hierarchy into the base class. 
What's a good way to improve/refactor such code? One alternative here would be to just use dynamic_casts to check for the types but that clutters the callers and adds a bunch of if-then-else all over the place. You can have more specific interfaces here but if all you have is the base class reference that doesnt help much either. Any other suggestions? Examples? 
Thanks!

A:

It seems like the problem is instead of implementing RequiresConcreteWall(), they implemented a flag call IsAfricanBison(), and then moved the logic on whether or not the wall should change outside the scope of the class. Your classes should expose behavior and requirements, not identity; your consumers of these classes should work from what they are told, not based of what they are.

A:

isAfricanBizon() isn't generic. Suppose you extend your animal farm with a hyppopotamus which is also too strong but returning true from isAfricanBizon() to have the proper effect would be just silly.
you always want to add methods to the interface which answer the specific question, in this case it would be something like strength()

A:

I think your problem is this: you have various clients of the library that are interested in only a subset of the hierarchy but that are passed a pointer/reference to the base class.  That is in fact the issue that dynamic_cast<> is there to solve.
It is a matter of design of the clients to minimize use of dynamic_cast<>; they should use it to determine if the object requires special treatment and if so do all the operations on the down-casted reference.
If you have "mix-in" type collections of functionality that apply to several separate sub-hierarchies, you might want to use the interface pattern that Java and C# use; have a virtual base class that is a pure-virtual class, and use dynamic_cast<> to determine if an instance provides an implementation for it.

