Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Class Design Question

Status
Not open for further replies.

Peppi

Programmer
Apr 9, 2001
205
CA
Hello,

I am creating a new Resource class to track scheduling information over a two-week period. This two week time period can be broken up into smaller time periods. So, I need to keep track of the start and end dates of these smaller time periods, plus some additional information specific to each period.

For example:
August 28 - August 30
Work Allocation - 100%
Type - Vacation

August 31 - September 1
Work Allocation - 75%
Type - Work

How would this be best implemented within my Resource class? I'm not sure in what type of data structure to store this (potentially) repeated information.

Thx.
 
What language are you using to write the program?
 
I'm just going by your examples, which do not imply any sort of two week period. They imply four attributes:
start date
end date
work allocation
type

Let's call this ResourceElement.

Now, though, you have mentioned that your resource class tracks information over a two week period. This implies another entity, related to the one I've just described. Let's call it Resource. Then, it will have a composition relationship with resourceelement, assuming a resource can't exist without resourceelements, and the converse.

So, a resource is composed of one or more resourceelements. A resourceelement is associated with one and only one resource.

That's how I would do it.

HTH

Bob
 
Can the time periods overlap?

It seems like a lot of hassle just for a 2 week period... Will there be multiple 2 week periods strung together? If so, what is the significance of the 2 week period vs the smaller ones vs the whole time line?
 
All very good questions, which only the OP can asnwer. However, I bet it has to do with payroll. 2 week pay periods, and the smaller periods have to do with ad hoc pieces of work allocated within the context of a pay period.

So Peppi, if you verify this, we can dig a little deeper.

Bob
 
My comment is intended to extend that of BobRodes a bit. It is based on the assumption that we are talking about non-decomposable resource of "PayPeriod" which by convention is a two week period that cannot overlap with any other period. Even though the resource is described by two distinct properties, start date and end date, it behaves essentially as a single resource and can be treated that way. (I assume also that some sort of strict validation routine enforces the business rules for start date and end date.)

With that in mind, I would implement PayPeriod as a class with a public class within it called PayPeriodElement. I would also create PayPeriodElements, which is a public collection class of PayPeriodElements. As Bob says, a PayPeriodElement cannot exist without a PayPeriod. This allows client code to create any number of PayPeriodElements for a single pay period (i.e. 50 percent work, 25 percent vacation, 25 percent sick time).

My recommendations beyond this get a little fuzzy, as my experience with using a design like this is limited. I welcome the comment of others about it. However, it seems to me that this is what Bob is getting at, and it has worked for me.

Charlie



 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top