Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm developing an application that allows people to place custom manufacturing orders. However, while most require similar paperwork, some of them have custom paperwork that only they require. My current class design has a Manufacturer class, of which of one of the member variables is an array of RequiredSubmission objects.

However, there are two issues that I am somewhat concerned about.

First, some manufacturers are willing to accept either a standard form or their own custom form. I'm thinking of storing this in the RequiredSubmission object, with an array of alternate forms that are a valid substitute. I'm not sure that this is ideal, however.

The major issue, however, is that some manufacturers have deadline cycles. For example, forms A, B and C have to be delivered by January 1, while payment must be rendered by January 10. If you miss those, you'll have to wait until the next cycle. I'm not exactly sure how I can get this to work with my existing classes—how can I say "this set of dates all belong to the same cycle, with date A for form A, date B for form B, etc."

I would greatly appreciate any insights on how to best design these classes.

share|improve this question
1  
There are two separate questions here. It's not easy to answer both in one post, especially as you fail to include the name of the language. Moreover, I don't see a concrete problem: "best design" is as vague as it gets. –  Deer Hunter Sep 4 '13 at 8:44

1 Answer 1

Part of the challenge you're having is because you aren't separating out the responsibilities appropriately. You also need to separate out the logical, or data construct, of the order from the physical order that will be placed.

Let's start with the orders. You should have a class MyMfgOrder that contains all the information you would need for generating a custom order. This will correlate pretty closely to the standard form you mentioned, but may have extensions due to custom form requirements. This is your logical order form construct.

Next, you'll need classes for each vendor's custom order form, such as VendorAMfgOrder. To simplify your life, have it take your MyMfgOrder as part of the constructor and then have the custom form build itself based upon your order form class. This would be one of several physical order form constructs.

I'll segue over to the Vendor class at this point. The Vendor has some specific properties, such as if they require a custom form and any dates associated with delivery. Locating this properties goes back to responsibility - the Vendor "owns" their need for a custom form as well as their delivery requirements.

When you go to work with an instance of the logical MyMfgOrder, you will end up selecting a Vendor at some point before placing the order. Once a Vendor is selected, you'll need to populate any delivery deadline information for that vendor as well as their accepted type of order form.

In my sample below, I didn't really specify how to track the particular forms to use because you didn't specify a particular language. And there are a number of ways to track what the final form needs to look like through enums, generics, arrays, or what not. The point is that MyMfgOrder represents a logical view of the order that will need to be transformed into a physical view of the order that is submitted to the actual vendor. It's appropriate for the logical view to understand what it's physical form should be.

Breaking things out that way allows you to keep track of the immediate concerns with some vendors and their particular delivery cycles. This also structures you so you can compare multiple vendors' requirements against each other for the same custom order. By using a logical order separate from the physical, you buy that ability to compare. You can also use the logical construct to generate repeating custom orders that are independent of any particular vendor since the physical order form is derived from the logical form.


Here's some sample code to layout the classes as I discussed.

public class MyMfgOrder
{
     Vendor PrefVendor;
     string StockNumber;
     int Quantity;
     float QuotedCost;
     DateTime QuotedDelivery;
     DateTime MustDeliverBy;
     DateTime MustPayBy;
     object FormToSubmit;
}

public class VendorAMfgOrder
{
    VendorAMfgOrder(MyMfgOrder myOrder) { }
}

public class Vendor
{
    bool RequiresCustForm;
    object CustFormType;
    DateTime DeliveryDeadlineCycle;
    DateTime PaymentDeadlineCycle;
}
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.