Yet another class design issue

[mrtinkles]

Hello all. I'm developing an asset management system in which users can place orders for various items. An administrator then assigns available items to the order which is then dispatched, received, returned etc.
The problem involves two main classes:

OrderItem - Keeps track of when it was hired, for how long etc

Item - Represents a specific item holding location, condition etc which is then assigned to an OrderItem

The problem I have is that OrderItem maintains a state with values such as: awaiting_assignment, dispatched, received, returned etc
It also then has methods such as assign, dispatch, receive which 'push' the OrderItem through it's various states.

My issue is that the above setup just doesn't feel quite right to me. For instance should OrderItem have a method such as dispatch()? Surely this is more suited to Item? Ideally I'd like to have OrderItem register itself as a listener of Item so it's state can change in sync with the Item status but I can't guarantee that both objects will be in memory at the same time. As such I've been using AOP to replicate this behaviour as best I can, loading the required OrderItem when needed and updating it 'manually'.

I apologise if this is turning into a ramble but it's a difficult problem to explain. If any further explanation is required ( which I suspect is highly likely ) I'd be happy to expand.

Any thoughts on the subject would be greatly appreciated

 

[jmeckley]

check out the state pattern. very similar to the stragety pattern. I haven't implemented this pattern too much. for a great explaination check out
Head First Design Pattern: chapter 10 "The State of Things" (pg 385)
1. define your states: awaiting assigment, dispatched, received, return
2. define your actions : assign, dispatch, recieve. etc.
3. create an interface for state with a function for each action.
4. create an implmentation of each state and define the actions which should be taken.

interface State
{
   void Assign();
   void Dispatch();
   void Recieve();
}

class Awaiting : State
{
   ctor (Item item)

   void Assign() 
   {
      //do something assign item
      item.SetState(item.Dispatch);
   }
   void Dispatch()
   {
      //do nothing or throw exception 
   }
   void Recieve()
   {
      //do nothing or throw exception 
   }
}
class Dispatched: State
{
   ctor (Item item)

   void Assign() 
   {
      //do nothing or throw exception 
   }
   void Dispatch()
   {
      //do something to item to dispatch item.
      item.SetState(item.Recieve);
   }
   void Recieve()
   {
      //do nothing or throw exception 
   }
}
class Recieved: State
{
   ctor (Item item)

   void Assign() 
   {
      //do nothing or throw exception 
   }
   void Dispatch()
   {
      //do nothing or throw exception 
   }
   void Recieve()
   {
      //do soemthing to item to recieve item
      item.SetState(item.Return);
   }
}

Item would look something like this

public Item
{
   private State awaiting = new Awaiting(this);
   private State recieved = new Recieved(this);
   private State dispatched = new Recieved(this);
   private State returned = new Returned(this);
   private State current;

   ctor()
   {
       current = awaiting;
   }

   public void SetState(State next)
   {
      current = next;
   }

   public State Receive { get { return received; } }
   public State Dispatch { get { return dispatch; } }
   public State Return { get { return returned; } }
}

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[mrtinkles]

Thanks for your reply jmeckley. Dealing with the state wasn't my primary concern but I will definitely be implementing that pattern at some point. Thanks for the detailed explanation, it's much appreciated.

I also posted on another forum where somebody has suggested I use JMS as a means or coordinating things which is my main problem. While looking for information on JMS I also came across this article:

http://www.ibm.com/developerworks/ibm/library/j-jtp0205.html

The section at the bottom entitled 'Classic MQ usage patterns' seems to describe my system pretty well so I'll pursue this for now.

Once again if anyone has any ideas or insight they can offer I'd appreciate their input.

Thanks in advance...