ajeru (no full-name supplied), says in How we have been betrayed:
Business people talk about A, B and C customers and they specify different rules that apply to A, B and C customers respectively. But we cannot easily have classes for these types of customers because the type of a customer is a dynamic property that changes at runtime. The result is, we cannot capture these business rules in the same way that domain experts do. What we do in our designs is to introduce methods like isAdult() or getCustomerType(). But neither can we use this kind of "typing" to specify constraints, nor can we organise method dispatching based on such types. No polymorphism, just switch statements.
It sounds like a perfect fit for the State Pattern to me. From Design Patterns, page 305.
Intent: Allow an object to alter its behaviour when its internal state changes. The object will appear to change its class.