Can an object take part in two state machines at the same time?

Question

I am writing an object oriented program whose business process calls for a "ticket" object. The "ticket" object acts in two ways. It is stock to be sold and it is stock we ourselves are either holding on a sale-or-return basis or have committed to buying.

For this reason a ticket in the sales process can have a state of being "available" or "sold" (there are other states but these are the important ones). A ticket also as a state with regards to its SOR status it is either "sor" or "purchased".

In theory it is possible for an "sor" ticket to be either "available" or "sold", it is also possible for a purchased ticket to be "available" or "sold". The two sets of states have almost nothing to do with one another directly. It is presumed a "sold" ticket will eventually become "purchased" and for an "available" ticket to never make it. That's about it.

So would I be right to design the object with two separate and independent states? Or should it only ever have one state which incorporates all of the above? What is best practice?

ADDITIONAL: So here's a headwrecker, whilst I'm waiting in the wings for some help on this one I've gone back to my analysis and there's another bizarre layer to this. "Tickets" have subobjects called "Prices" this accounts for having a ticket that could be sold to an adult at one price, a child at another and a pensioner at yet a third.

When a ticket is in the "SOR" state that is noted at the ticket level, but when it enters the "Purchased" state that is logged against the Price because a ticket can have multiple possible prices but when it is paid for it is only paid for at one level (this is to do with things like venue capacities).

Similarly when the ticket is "available" it has multiple possible prices but it is "sold" against the "Price" because that's when a customer has made a decision to purchase, for example, one adult, two child tickets. The tickets for a given event could be entirely bought up by adults, or mostly sold to children, and obviously usually somewhere in between but the information related to the states happen in two different objects. Does this make a difference?

Answer 1

If the states themselves are truly independant then it seems to me that writing

ticket:
   availability: available or sold
   sor: sor or purchased

is much cleaner than what you'd get with a single state, which I guess would have to look like

ticket:
      available_&_sor
      available_&_purchased
      sold_&_sor
      sold_&_purchased

In the first case, you're treating the object as if it has a discrete availability state, as well as a discrete sor state, which sounds like it models your real world example clearly. In the second you have one artificial state that encodes these two values.

The difference between the two becomes magnified if you have more types of each discrete state, and suddenly you start having lots of combinations.

Answer 2

If the behavior on the two axes is independent (and particularly if there are conceivable subtypes or variant objects with overlapping behavior) it might make sense for Tickets to hold onto two state objects and to build its behavior out of the behavior of the separate state objects.