View source

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

==The "becomes" problem == You want an object to change its behavior but stay the 'same' object. An example of this is given in the [[Frogs design]]: have a frog object that must somehow change from egg to tadpole to frog (and ultimately to dead frog), wiht different ways of moving, but stay a frog. The problem is that inheritance is not dynamic. This is one example of the weakness of '[[Model the real world|model the real world]]' as a design maxim: in the real world we easily accept that the tadpole is the "same" as the adult frog but our notions of type in the real world are much richer and more complex than interface and behaviour. The "becomes" problem is often indicated by type switches (see [[Beware type switches]]). See Riel's heuristic "[[Avoid becomes|Do not model the dynamic semantics of a class with inheritance]]".

Return to Becomes problem.