Arbeiten mit java.time in Kotlin: Liebe, Schmerz, Leiden

Ein Mikropost darüber, wie Sie sich bei Verwendung der Kotlin-Funktion täuschen können: die Möglichkeit, mit Vergleichsoperatoren wie Comparable zu arbeiten.





Diejenigen, die Kotlin verwenden, konnten nicht anders, als die Überladung des Operators zu schätzen (genauer gesagt, wie es gemacht wird), obwohl ich sagen werde, dass ich in Java gelebt habe und es ohne es in Ordnung ist, aber es geht nicht um diese Sprachfunktion, sondern darum die darauf basierende: Vergleichsoperationen. In diesem Fall können Vergleichszeichen auf Klassen angewendet werden, die Comparable implementieren, was Zucker ist, aber sehr schön.





Lassen Sie uns also mit Kunststoffen üben: Wir haben eine gewisse Zeitspanne, d. H. Start- und Enddatum und -zeit und wir müssen die Tatsache der Überschneidung von Zeitintervallen überprüfen.





In Java (ich schreibe so kurz wie möglich und ohne akzeptierte Normen, vermitteln Sie einfach die Idee):





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));
  }
}
      
      



jene. nichts kompliziertes, aber nur für den Fall, dass ich den Code erklären werde (ich muss mir diesen Code erklären, wenn ich ihn treffe): Der Schnittpunkt zweier Intervalle ist nur möglich, wenn das Startdatum eines Intervalls früher oder gleichzeitig in Beziehung steht Das Enddatum des zweiten und gleichzeitig das Enddatum des ersten Intervalls liegt später oder am Anfang des zweiten Intervalls.





Jetzt das gleiche aber auf Kotlin mit seinem Zucker, aber ohne die Ranger:





data class TimeInterval(val from: LocalDateTime, val to: LocalDateTime)
fun areOverlapped(first: TimeInterval, second: TimeInterval): Boolean = 
  first.from <= second.to && first.to >= second.from
      
      



Nun, ich denke ohne Kommentare, wo man besser sehen kann, was angenehmer zu bedienen und schneller zu verstehen ist. Zufrieden gehen wir zu Kotlin und beginnen analog mit OffsetDateTime zu arbeiten.





, 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))
      
      



Natürlich ist es richtig, hier nicht isEqual zu verwenden, sondern - == und im Allgemeinen getrennt isEqual + isBefore + isAfter und Comparable + gleich, aber leider neige ich manchmal dazu, den Unterschied nicht zu bemerken, insbesondere wenn ich einen bequemen Ansatz mit Vergleichsoperatoren habe .





Auf diese Weise können Sie auf einfache und natürliche Weise einen nicht offensichtlichen Fehler bei der gedankenlosen Verwendung von Vergleichsoperatoren in Kottlein mit der java.time-API erstellen.








All Articles