Looking at an object through different lenses depending upon which aspects and relationships you want to emphasize is indeed a very powerful way of utilizing code. However, it would be a mistake to try to accomplish that by altering the inheritance chain at runtime, or frivolously between compilations for that matter, for the practical reason that trying to build an inheritance structure flexible enough to allow that without breaking is damn hard, and for the theoretical reason that to say that a class is a descendant of a particular base class is to say something permanent about the kind of being that it is, not to indicate a transitory characteristic.

The problem stems at least in part from the ambivalence in English of the word "is". Clinton was not entirely BSing in his deposition, because the word can mean one of three things: the assignment of a predicate to a noun, i.e., "the tie is gold"; a strict identification between two or more things, i.e., "the dress with the stain is the blue dress"; or it can indicate subsumption under a general category, i.e., "he is a man".

In comparison, look at the difference between estar and ser in Spanish. both mean "to be", however "estoy en Norteamérica" means "I am in North America", and "soy norteamericano" means "I am a North American". It's the difference between a characteristic that is incidental to who and what I am, and one that is intrinsic to the kind of being that I am. Inheritance in an object model ought to capture only the latter.

Now I'm not going to argue that there is no bleedover between the three variations of "is", especially between the ascription of predicates and the placement of an object under a general category. For example, if a person works as a trainspotter for a single week, does it make sense to say that that person is in any way intrinsically a trainspotter? In the same way that he/she is a mammal? Probably not, but it might make sense to say that of a person who's been a trainspotter for his/her entire adult life. Nonetheless, in planning out an object model utilizing inheritance you have to think about what defines your classes in their most basic, abstract, and essential sense. In many cases, it won't be sensible or sufficiently flexible and powerful to explain immediately what something "is" by looking for an inheritance relation. Rather, what you would find better in your example above is to define a class Job that a Person could possess, and a class FamilyRelation to describe the Person as a father, sister, etc., and perhaps a BehavioralModes class for being a jerk or hero. Altering the fundamental being of an object is something that should happen only under conditions of extraordinary stress. But I would not say it should never happen, so just long as the rules according to which it will are clearly laid out in advance.

Good Question!