Fog Creek Software
Discussion Board




Object Oriented program abstract

what is an Order?

To the sales department it might be a customer signing a contract to order a product.

To manufacturing it is only an "official" order when all of the specifications have been agreed to after review at the plant.

To accounting it may only be after an invoice has been generated.

How might this complicate object oriented abstraction? How can we clear up the issues?

Doha
Friday, July 16, 2004

Have the "order" go through an assembly line-like series of states, where the states designate to whom the order appears as such.  Sales might be state 1, managers might be state 2, etc.  For the order's state to change, it must have encountered signature x, token y, stamp z, etc.

sir_flexalot
Friday, July 16, 2004

oops, I meant manufacturers, not managers.

sir_flexalot
Friday, July 16, 2004


I do this with PO's (Purchase Orders) and RMA's (Return Merchandice Authorizations).

There are a handful of states that each thing will go through and upon entering a given state, notifications are sent to the responsible parties.

KC
Friday, July 16, 2004

I agree with flexalot.  Your order has a workflow associated with it, which you can track with states.  It may be worthwhile to look into a rules engine or workflow engine if you have enough business rules to track.  Implementing them through an engine instead of "hardcoding" them in source code makes it easier to update business rules and add new ones, at an up-front cost of having to spend the effort of integrate the engine.

Should be working
Friday, July 16, 2004

Another option is to define the order by your first definition.  An order is a request to purchase x items at y cost.  Then what manufacturing and accounting look at are associated tracking objects that are associated with the order.

So you'd have an Order object containing the details of the purchase, and an OrderTracking object containing dates related to the order.  (Or you could comprimise and put those dates in the order, but not make them required.)

Brian
Friday, July 16, 2004

Thank you all for your help.

Doha
Friday, July 16, 2004

Footnote:

Be sure that if you have the object mean different things depending on state (a very good solution) you also make sure that it doesn't overwrite relevant information from a previous state.

For example, when a customer places an order, deliveryDate might be the date he would like it to arrive.  When your object's state changes, don't change the meaning of deliveryDate to be, say, the estimated date of delivery, because now you've lost information regarding the previous state (namely, the day the customer wants the item to show up).


Friday, July 16, 2004

Doha,

you need to change the semantics of your order class. Use the decorator pattern - for each semantic you need to implement, aggregate the order into a wraper class - eg CustomerOrder, AccountingOrder, etc. This should give you different behaviour for same data.

Using the state pattern is not exactly right since your order changes semantics, not state. Well it may change state but that's another problem.

Cheers
Dino

Dino
Saturday, July 17, 2004

Thank you all for your response.

Dan
Saturday, July 17, 2004

Thank you all, I appreciate your help.

Doha
Saturday, July 17, 2004

*  Recent Topics

*  Fog Creek Home