-2

I am designing the software to calculate employees' hours among others. To simplify my problem let's say that I have Activity class, which has a property Type. This type could be for example "Standard work", "Overtime work","Business travel" etc. As an input I have a timesheet. I can have a lot of cases here, but let's focus on the two below:

  1. In this timesheet there is an entry from 8:00 to 16:00 -> I need to create one Activity (Standard work)
  2. In this timesheet there is an entry from 8:00 to 17:00 -> I need to create two Activities ( one instance for Standard work and one instance for overtime work with a duration of 1hour)

I was thinking about the builder pattern, but I am not sure if this the right path,

P.S No, I can't keep standard work and overtime work data in one class.

  • Unless I'm missing something, this should be as simple as having a function that takes a Timesheet and returns a List<Activity>. – casablanca Dec 25 '19 at 19:09
1

Your intent is to create instances of Activity based on Timesheet object input. Some properties of the created Activity are derived from Timehsheet data.

At a first sight, there is no need for a special design pattern here. This is business as usual. Design patterns are not a mandatory step to design software. It's just some frequently known challenges with ideas how to address them.

You could however have some additional design intents. And depending on those, there could be some relevant design pattern. I don't know if you are in this situation, but here a couple of examples:

  • Maybe the Activity needs lots of properties at construction, and you want to simplify the creation process by isolating all the details of the property preparation. In your case, you could for example have some business rules that define what property can be derived how. In this case you could indeed be interested in Joshua Bloch's builder pattern.
  • But if the sole property is the Type, you may as well just use a business rule object to isolate a complex rule, without using a builder pattern. After all, this business rule could make sense outside the creation of an activity (e.g. in a time sheet validation). Again, no specific design pattern.
  • Maybe you envisage specialisations of Activities, and you may want to create activities without knowing in advance the specialisation to be used. In this case you could consider the factory method. Factory method could by the way be combined with the invokation of the above mentioned business rule that could be injected into the factory (when the factory is set up).
  • Maybe the Factory is interesting for your case but Activity is only one piece of the puzzle, and you have a couple of related classes that need to be constructed as well and in a consistent manner. In this case, you may prefer an abstract factory.
  • Finally, you may have a very complex Activity that requires several steps to be constructed, and have several different representations of activities. In this case the GoF builder pattern would be an option. But I have the impression it would be overkill here.

I do not know your context, nor do I have the big picture of the intended design. This is up to you to decide. But intuitively, I have the impression that a factory could be a very relevant option here.

Your Answer

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

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