OOP approach for inventory system

We're developing a system to track inventory at our field offices.

At its core, the system will have a list of "Assets" - things like Bikes, Computers, Tents. Each Asset goes through states like "Active", "Lost", "Checked Out", "Inventoried". Some states have additional information, like "Checked Out To" or "Inventoried By".

So, I'm thinking each State will be a subclass of a parent class or perhaps implement a iState interface. That part is clear to me.

What I'm stuck on is a good OOP design to put the business logic of what states can follow the previous state (The Asset object will store it's "last" state). For example, Checked In can only follow Checked Out. Active must be the first state recorded on an Asset.

Any ideas or pointers would be helpful. None of the GoF design patterns jumped out at me on this one.

And yes, I know we should be looking at COTS, but management has decided to proceed with rolling our own tool for now.

From stackoverflow

• Hmm. That sounds like more like a work flow/business rule issue than OOD. I don't know of any OO principles that enforce order/dependencies of state like you describe.

• You sort of answered your own question. Check out the State pattern.

  matt eisenberg : couldn't see the forest for the trees...