Il existe des types plus généraux partagés par ces classes, tels que Temporal
. Mais ils ne sont généralement pas censés être utilisés par les développeurs d'applications.
Et ces types plus généraux ne partagent pas les méthodes isBefore
/isAfter
.
Je pense que vous êtes induit en erreur par les méthodes aux noms fortuits, en pensant que ces classes de date-heure ne sont que des variations les unes des autres. Mais ce n'est pas le cas. Un LocalDate
est vraiment une bête différente d'un LocalDateTime
. Ainsi, en référence à votre balise DRY, vous ne vous répétez pas vraiment ici. Essayer d'abstraire la distinction entre une date unique et une date avec heure n'est pas valide.
En revanche, remarquez comment LocalDate
implémente l'interface plus générale ChronoLocalDate
, d'où proviennent les méthodes isBefore
/isAfter
. Cette interface est partagée entre cinq classes dans Java (HijrahDate, JapaneseDate, LocalDate, MinguoDate, ThaiBuddhistDate) et encore plus de classes dans le projet ThreeTen-Extra. Ces classes sont du même type, différentes manières d'identifier chaque date sur un calendrier. Pour ces classes, l'abstraction de toutes ces classes en tant que ChronoLocalDate
est logiquement appropriée et (apparemment) utile au framework java.time.
Notez que je ne suggère pas l'utilisation de ChronoLocalDate
dans votre application. La Javadoc nous met clairement en garde contre une telle utilisation en règle générale. Je cherche simplement à montrer que les classes de date unique sont "un peu les mêmes" tandis que les classes de date unique et de date avec heure ne le sont pas.