State Pattern Vs. Polymorphic Employee

Plenty of reasons to favor the State Pattern:

In this case, implementing the promote logic in the subclasses would be quite challenging as we can not change the type of a class at runtime. It could be done by changing the Promote method signature to return an Employee. The subclasses could then each implement Promote that returned an appropriate subclass of employee. However, this solution feels contrived. It is also more difficult to understand for a future maintenance programmer and could lead to hard to find bugs.

Another reason we may not wish to have a polymoprhic Employee class is because there may be multiple state objects in a single domain object. What if we need not only to compensate and promote employees based upon their position, but also to assign vacation days based upon the project to which the empoloyee is currently assigned? A situation where we needed a class for TechnicalLeadWhoIsWorkingOnProjectX arises.

Another reason [...]

http://nathan.whiteboard-it.com/archive/2008/09/01/state-pattern.aspx