3

I have the following code:

LocalDate date;
LocalDate minDate;

//constructor...

if(date.isBefore(minDate)){
   throw new RuntimeException();
}

and similar with LocalDateTime:

LocalDateTime date;
LocalDateTime minDate;

//constructor...

if(date.isBefore(minDate)){
   throw new RuntimeException();
}

Can I use some interface or abstract class thanks to which I wouldn't have to write the same code twice? I can't find such an interface. As you can see I am using only 'isBefore' and 'isAfter' methods.

Karord
  • 105
  • 6

2 Answers2

4

There are more general types shared by these classes, such as Temporal. But they are not meant to be used by app developers generally.

And those more general types do not share the isBefore/isAfter methods.

I think you are being fooled by the coincidentally named methods into thinking that these date-time classes are mere variations of each other. But they are not. A LocalDate is really a different animal than LocalDateTime. And so, in reference to your DRY tag, you actually are not repeating yourself here. Trying to abstract away the distinction between a date-only and a date-with-time is not valid.

In contrast, notice how LocalDate implements the more general interface ChronoLocalDate, where the isBefore/isAfter methods come from. That interface is shared among five classes within Java (HijrahDate, JapaneseDate, LocalDate, MinguoDate, ThaiBuddhistDate) and even more classes in the ThreeTen-Extra project. Those classes are the same kind of animal, various ways to identify each date on a calendar. For these classes abstracting all these classes as a ChronoLocalDate is logically appropriate, and (apparently) useful to the java.time framework.

Note that I am not suggesting the use of ChronoLocalDate in your app. The Javadoc clearly warns us against such usage as a general rule. I’m merely trying to show that date-only classes are “kind of the same” while date-only and date-with-time classes are not.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • I agree completely. The two snippets in the question indeed have a similarity, but look more similar than they are because the `LocalDateTime` is misnamed `date`. It should be `dateTime`. Had the fields had type `Integer` and the check been `integer < minInteger`, the similarity would have remained. Trying to abstract such similarity away has no gain, only needless complication. – Ole V.V. Nov 29 '21 at 09:38
-1

Instant. Both LocalDate and LocalDateTime can be converted to Instant.

rongfeiyue
  • 129
  • 4
  • 2
    Not true at all. An `Instant` represents a moment, a specific point on the timeline. Neither `LocalDate` nor `LocalDateTime` represent a moment. To get to a moment you would have to add information, a time-of-day and/or time zone, which is not already present. – Basil Bourque Nov 29 '21 at 07:49
  • It is not working fine because I need to parse everytime – Karord Nov 29 '21 at 07:50
  • 1
    That is indeed a wrong answer. Sorry about that. And i saw your answer about the question "difference between Instant and LocalDateTime". I got a lot ,thanks Basil Bourque. – rongfeiyue Nov 29 '21 at 08:19
  • 1
    https://stackoverflow.com/questions/32437550/whats-the-difference-between-instant-and-localdatetime/32443004#32443004 – rongfeiyue Nov 29 '21 at 08:20