tags:

views:

175

answers:

2

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.

A: 

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.

Jim Anderson
+2  A: 

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

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