views:

62

answers:

3

Hi there,

I want to describe the following situation in an UML Classdiagram:

A day, on which a newspaper is send to a customer. This day could be sth. like "every friday" or "every first day of a month".

My idea to represent this in a UML Classdiagram:

-targetDay:Integer
-targetDayGrid:Enumeration

targetDay would be sth. like "1" (for monday) oder "5" (for friday) or it could be "1" for the first day of the month or "10" for the 10th day of the month.

targetDayGrid is an enum: weekly, monthly.

So the enum sets the semantic meaning of the number in targetDay. I´m not happy with this, do you know any other solution to represent my problem? Or do you think my solution is okay?

+1  A: 

In my opinion, I would separate the two and model the class with 2 enums like

public enum Day_Of_Week{ SUN, MON, TUE, WED, THU, FRI, SAT }

public enum Day_Of_Month{ 1, 2, .. , 31 }

This avoids any incorrect setting of value > 7 to the targetDay for "Day of week"

JoseK
I´m thinking about an rule engine... perhaps a better idea.
Tobiask
+1  A: 

This could sound a bit overkill but I think that you need three more classes here: TargetDay that would be a abstract class (or an interface), WeeklyTargetDay and MonthlyTargetDate that would provide different implementations of TargetDay alt text

Maurice Perry
I´m thinking about an rule engine... perhaps a better idea.
Tobiask
not so sure ...
Maurice Perry
why not? I think it could be an alternative...
Tobiask
Well you will need some attributes to define the recurrence, and the attributes will depend on the nature of the recurrence. This is typically a problem that can be solved using polymorphism (subclassing/interface implementation)
Maurice Perry
+1  A: 

It really looks like a good idea to separate actual date retrieval and computation of that date from each other, but this could not hold in every situation, e.g. when you want to pre-compute more values and you can do it more efficiently computation method by computation method than customer by customer. This will also allow for future addition of new methods (biweekly delivery, different delivery schema during holidays...). It could be dangerous to have value with semantics dependent on other value. You also want to avoid errorneous data, maybe using enums as suggested, especially for days in a week (don't forget, that not every month has the same length, you would need some Date class with checking rather than just an enum). However if you are looking for the simplest solution, try two variables - day in a year and a day multiplier (but don't forget, that not every year has the same amount of days...).

Gabriel Ščerbák