Un micro-article sur la façon dont vous pouvez vous tromper lors de l'utilisation de la fonctionnalité Kotlin: la possibilité de travailler avec des opérateurs de comparaison comme Comparable.
Ceux qui utilisent Kotlin ne pouvaient s'empêcher d'apprécier la surcharge des opérateurs (enfin, plus précisément, comment cela se fait), même si je dirai que j'ai vécu en Java et que tout va bien sans cela, mais il ne s'agit pas de cette fonctionnalité de langage, mais de celui basé sur celui-ci: Opérations de comparaison. C'est à ce moment que les signes de comparaison peuvent être appliqués aux classes qui implémentent Comparable, ce qui est du sucre, mais très agréable.
Et donc, pratiquons sur les synthétiques: nous avons une sorte de période de temps, c.-à-d. date et heure de début et de fin et nous devons vérifier le fait de l'intersection des intervalles de temps.
En Java (j'écris le plus brièvement possible et sans normes acceptées, il suffit de transmettre l'idée):
class TimeIterval {
LocalDateTime from;
LocalDateTime to;
}
class TimeIntervalUtil {
public boolean areOverlapped(TimeInterval first, TimeInterval second) {
return (first.from.isEqual(second.to) || first.from.isBefore(second.to)) &&
(first.to.isEqual(second.from) || first.to.isAfter(second.from));
}
}
ceux. rien de compliqué, mais juste au cas où j'expliquerais le code (je dois m'expliquer ce code quand je le rencontre): l'intersection de deux intervalles n'est possible que si la date de début de l'un est venue plus tôt ou en même temps par rapport à la date de fin du second et à la même heure, la date de fin du premier intervalle vient plus tard ou au début du second.
Maintenant la même chose mais sur Kotlin avec son sucre, mais sans les rangers:
data class TimeInterval(val from: LocalDateTime, val to: LocalDateTime)
fun areOverlapped(first: TimeInterval, second: TimeInterval): Boolean =
first.from <= second.to && first.to >= second.from
Bon, je pense que sans commentaires où l'on voit mieux, qu'est-ce qui est plus agréable à utiliser et à comprendre plus vite. Satisfaits, nous allons à Kotlin et commençons à travailler par analogie avec OffsetDateTime.
, OffsetDateTime. Comparable, java.time. LocalDateTime. Java , .
compareTo, Kotlin , LocalDateTime ( , , ), .
OffsetDateTime , , compareTo , .. 2021-04-25 10:00+0 2021-04-25 11:00+1 . :
val inUtc = OffsetDateTime.of(LocalDateTime.of(2021, 4, 25, 10, 0), ZoneOffset.UTC)
val inUtc1 = OffsetDateTime.of(LocalDateTime.of(2021, 4, 25, 11, 0), ZoneOffset.ofTotalSeconds(60*60))
println(inUtc1>=inUtc && inUtc1 <= inUtc)
println(inUtc.isEqual(inUtc1))
Bien sûr, il est correct d'utiliser not isEqual ici, mais - == et généralement séparé isEqual + isBefore + isAfter et Comparable + equal, mais malheureusement, j'ai parfois tendance à ne pas remarquer la différence, surtout lorsque j'ai une approche pratique avec des opérateurs de comparaison .
C'est ainsi que vous pouvez facilement et naturellement créer un bogue non évident dans le cas d'une utilisation irréfléchie des opérateurs de comparaison dans Kottlein avec l'API java.time.