ProgrammatieBackend ontwikkelaar

Leg uit hoe de operators '==' en '===' werken in Kotlin. Wat is de specificiteit van het vergelijken van objecten en waarde types, wat gebeurt er onder de motorkap bij het vergelijken, en hoe voorkom je de veel voorkomende fout met gelijkwaardigheid?

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord.

In Kotlin zijn er twee operators voor vergelijking:

  • ==structurele vergelijking (equivalent aan .equals()). Het controleert de inhoud: a == b roept a?.equals(b) ?: (b == null) aan.
  • ===referentie vergelijking. Controleert of beide variabelen naar hetzelfde object verwijzen: a === b is gelijk aan de Java a == b voor objecten.

Voor primitieve types (bijvoorbeeld, Int): == en === kunnen zich gelijk gedragen door autoboxing, maar over het algemeen moet == worden gebruikt.

Voorbeeldcode

val a = "Kotlin" val b = "Kotlin" val c = a println(a == b) // true (inhoudsvergelijking) println(a === b) // false (verschillende referenties — strings zijn geïnterneerd afhankelijk van de compiler) println(a === c) // true (zelfde object)

Vraag met een valstrik.

Wat is het verschil tussen a.equals(b) en a == b in Kotlin?

Sommigen beweren dat er geen verschil is, maar als a nullable is, zal het aanroepen van a.equals(b) een NullPointerException veroorzaken, terwijl a == b veilig is en true retourneert als beide null zijn, of false als slechts een van beiden null is.

Voorbeeld:

val a: String? = null val b: String? = null println(a == b) // true println(a?.equals(b)) // null (en niet true, maar geen crash) println(a.equals(b)) // NullPointerException

Voorbeelden van echte fouten door onbekendheid met de nuances van het onderwerp.


Verhaal

In een groot project werden nullable strings actief vergeleken met a.equals(b), niet wetende dat bij a == null de applicatie crasht. De bug kwam redelijk zelden voor, maar leidde tot fatale crashes in productie — dit werd opgelost door te vervangen door a == b.


Verhaal

Bij het vergelijken van objecten via === werd verwacht dat de inhoud vergeleken werd, maar === controleert de identiteit van objecten — het bleek dat twee verschillende strings met dezelfde inhoud niet gelijk zijn via ===, wat de logica van gegevenscaching verbrak.


Verhaal

Bij het werken met boxed Int-waarden (bijvoorbeeld uit collecties), vergeleken ontwikkelaars deze via === en kregen onverwachte resultaten omdat objectinstanties van verschillende getallen niet noodzakelijkerwijs geïnterneerd worden als primitieve waarden. Dit leidde tot onjuist gedrag bij het werken met verzamelingen van objecten.