New answers tagged

0

The problem is that your trying to represent dynamic periods (YEAR_TO_DATE and SINCE_CREATION) in an enum, StandardDatePeriod. Although both are periods, the period of time they cover are unknown at compile time. So, in that sense, the enum is not the right tool. However, the other periods (e.g. ONE_MONTH) are fixed and known at compile time. So, they work ...


0

Would the StandardDatePeriod be used in other contexts? Because if it is only used in contexts where Product is known, I would see it fitting to move the logic from where you determine the start date into the StandardDatePeriod objects themselves, as having this logic outside seems to be a form of abstraction leaking from the Period concept you have in place....


0

You need a method to convert the enum into it’s currently correct meaning. I’d recommend NOT to use “correct” values for 6, 12 etc. Months so that nobody assumes this will always work. You don’t want code written that works for the first five enum values (and fails horribly for the other two).


2

Go on with enums? You could keep using your enum and use some tricks and magic numbers for special cases. 0 for SINCE_CREATION was already suggested. Why not 9999 for YEAR_TO_DATE and so on. But this design is not open for extension nor closed to modification: First, you'll have to add some if..else and switch to deal with all the special situations and ...


2

A Java enum is a nice tool for the job, as you can override the methods in the concrete constants. The problem you face is, that you need a common signature. Thus, when one concrete implementation needs a productCreateDate, you'll have to pass it into the methods for all implementations. As you extend your enum with more and more specific constants, this may ...


Top 50 recent answers are included