I'm currently starting a new sub project where I will:

  1. Retrieve the order information from our mainframe
  2. Save the order information to our web-apps' database
  3. Send the order as EDI (either D01b or D93a)
  4. Receive the order response, despatch advice and invoice messages
  5. Do all kinds of fun things with the resulting datasets.

However I am struggling with my initial class designs.

The order information will be retrieved from the mainframe which will result in a "AOrder" class, this isn't a problem, I am not sure about how to mold this local object into an EDI string.

Should I create EDIOrder/EDIOrderResponse/etc classes with matching decorators (EDIOrderD01BDecorator, EDIOrderD93ADecorator)? Do I need builder objects or can I do:

// $myOrder is instance of AOrder
$decorator = new EDIOrderD01BDecorator($myOrder);
$edi = $decorator->getEDIString();

And it'll have to work the other way around as well. Is the following code a good way of handling this problem or should I go about this differently?

$ediString = $myEDIMessageBroker->fetch();
$ediOrderResponse = EDIOrderResponse::fromString($ediString);

I'm just not so sure about how I should go about designing the classes and interactions between them.

Thanks for reading and helping.

migrated from codereview.stackexchange.com Nov 12 '11 at 15:25

This question came from our site for peer programmer code reviews.


If the only point of the EDIOrderD01BDecorator is to produce an EDI String, then I would create a EDIOrderSerialization class with static methods to deserialize and serialize in the various necessary formats.

Elsewise if there is further processing to do with an EDIOrder object instead of AOrder, then I would go with the decorator pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy