In Kotlin wordt operator overloading ondersteund via het sleutelwoord operator. Dit stelt je in staat om je eigen logica te definiëren voor de standaardoperatoren (+, -, *, [], ==, enz.) voor gebruikersdefinierte types:
operator.Voorbeeld:
data class Vec2(val x: Int, val y: Int) { operator fun plus(other: Vec2) = Vec2(x + other.x, y + other.y) } val a = Vec2(1,2) val b = Vec2(2,3) val c = a + b // zal operator fun plus oproepen
Nuances en beste praktijken:
== en equals moeten consistent zijn).Wat is het verschil tussen het overladen van de operator
==en het overschrijven van de methodeequals()?
Antwoord: De operator == in Kotlin roept altijd de methode equals() aan (met een voorafgaande null-check). Als je operator fun equals(other: Any?): Boolean definieert, zal de operator == altijd deze methode gebruiken. Het is niet mogelijk om == en equals() anders te laten werken.
data class Point(val x: Int, val y: Int) { override operator fun equals(other: Any?): Boolean { ... } } val a = Point(1,2) val b = Point(1,2) println(a == b) // zal a.equals(b) oproepen
Geschiedenis
Overlaadde de operator compareTo zonder duidelijke semantiek:
In de klasse Point definieerde we operator fun compareTo om te gebruiken in sorteringen. Echter, "meer" en "minder" hadden geen duidelijke betekenis, verschillende teamleden schreven verschillende logica. Het resultaat - verwarrende bugs bij het sorteren van collecties.
Geschiedenis
Vergeten over de symmetrie van operatoren voor wederzijds type:
Een ontwikkelaar implementeerde operator fun plus(a: Matrix, b: Vector): Matrix, maar zorgde niet voor de werking van Vector + Matrix, omdat hij de symmetrische functie niet implementeerde.
Als gevolg hiervan compileerde de expressie vector + matrix niet, alleen matrix + vector werkte. Dit veroorzaakte bugs in veel delen van de code.
Geschiedenis
Onjuiste overbelasting van de operator get:
Een ontwikkelaar maakte een custom-klasse en overlaadde operator fun get(index: Int): Foo. Hij voegde geen checks voor out-of-bounds toe - en een poging om toegang te krijgen tot een niet-bestaand element gaf een object met ongeldige velden terug, in plaats van een uitzondering te gooien - wat leidde tot "onzichtbare" fouten in de businesslogica.