The notion that an object may change class during its lifetime. Most OO programming languages enforce StaticClassification. (Smalltalk allows dynamic classification but it is considered to be bad style.) The term was made known by JamesOdell.

If you are modeling how people think about the world it is perfectly reasonable to think of objects changing class as normal. The idea that an object's class is static is really just a constraint imposed by OO programming languages.

I used to make a point of using DynamicClassification? when doing conceptual modeling, but have mellowed on that now. However when I'm working with domain experts I'll happily represent states as subclasses, and switch them to the StatePattern or something later on

-- MartinFowler
----
I agree, I usually use subclasses or even related classes for modelling. Once the modelling is done, I can always decide how to implement that. Using the StatePattern is not in my preferred BagOfTricks. Having different classes is the preferred option for me, so that I can always add more behavior to classes and keep them small. At the end classes are so simple I can always add more requirements without any effort. Well, sometimes I need to refactor the code first (which usually means adding a lot more classes), but in my tiny mind that is not bad style, that's just how ObjectOrientation goes.

-- GuillermoSchwarz

-------------

As a RelationalWeenie, can I put my two cents in on this issue? Thank you. Relational thinking tends to "backload" classification, while OO tends to "frontload" it. By this I mean that OO tends to want to put the classification into designs up-front; but relational is more concerned about describing the domain nouns (DatabaseIsRepresenterOfFacts). In theory if the description is sufficient, then one can get any view (classification) they want when they need it. If there are not enough facts in the database to get the right result, then they need to be put in (GiGo). Thus, relational "backloads" it, putting the burden of classification on the query builder, not on the original system builder. I feel this makes a system more flexible and adaptable, but counter viewpoints are welcome. --top

''Depends on the language.  In Java or C++, you're point is largely correct--types must be specified up front.  In Smalltalk or Python, "types" in the language correspond more to protocols (the union of all methods an object understands) than to classes (the "factories" used to produce the objects).  This is more similar to relational schemata, where the "type" of a relation or a record corresponds to the attributes and constraints it has, rather than to any name it is given.''

I agree that SmallTalk-like languages do tend to have a PredicateDispatcing nature. But they lack built-in CollectionOrientedProgramming, leaving that up to the application developer or class builder, for good or bad (I personally think it is bad because it leads to poor InterfaceFactoring and inconsistency).

----

See also TypeMigration