Remplacer getter pour Kotlin classe de données

Après avoir passé près d'une année complète de la rédaction de Kotlin au quotidien, j'ai trouvé que le fait de chercher à remplacer les classes de données comme c'est une mauvaise pratique. Il y a 3 approches valables pour le présent, et après je leur présente, je vais vous expliquer pourquoi l'approche d'autres réponses ont suggéré est mauvais.

1. Ont une logique d'entreprise qui crée la data class modifier la valeur à 0 ou plus avant d'appeler le constructeur de la mauvaise valeur. C'est probablement la meilleure approche pour la plupart des cas.

2. N'utilisez pas de data class. L'utilisation régulière d'un class et votre IDE générer la equals et hashCode méthodes pour vous (ou pas, si vous n'en avez pas besoin). Oui, vous allez avoir à re-générer si les propriétés sont modifiées sur l'objet, mais vous êtes de gauche avec un contrôle total de l'objet.

   class Test(value: Int) {
     val value: Int = value
       get() = if (field < 0) 0 else field
   
     override fun equals(other: Any?): Boolean {
       if (this === other) return true
       if (other !is Test) return false
       return true
     }
   
     override fun hashCode(): Int {
       return javaClass.hashCode()
     }
   }

3. Créer un nouveau coffre-fort à la propriété sur l'objet qui fait ce que vous voulez au lieu d'avoir une valeur privée c'est effectivement surchargé.

   data class Test(val value: Int) {
     val safeValue: Int
       get() = if (value < 0) 0 else value
   }

Une mauvaise approche que d'autres réponses sont ce qui suggère:

data class Test(private val _value: Int) {
  val value: Int
    get() = if (_value < 0) 0 else _value
}

Le problème avec cette approche est que classes de données ne sont pas vraiment conçus pour modifier les données de ce genre. Ils sont vraiment simplement pour conserver les données. Primordial de la lecture pour une classe de données comme cela signifierait que Test(0) et Test(-1) ne serait pas equal l'un de l'autre et auraient des différents hashCodes, mais quand vous avez appelé .value, ils auraient le même résultat. C'est incohérent, et tandis qu'il peut travailler pour vous, d'autres personnes dans votre équipe qui a le voir c'est une classe de données, peut accidentellement en abuser sans se rendre compte de la façon dont vous avez modifié /le fait de ne pas fonctionner comme prévu (c'est à dire que cette approche ne fonctionne pas correctement dans un Map ou un Set).

La réponse dépend de ce que les capacités que vous utilisez réellement que data fournit. @EPadron mentionné un truc astucieux (version améliorée):

data class Test(private val _value: Int) {
  val value: Int
    get() = if (_value < 0) 0 else _value
}

Qui fonctionne comme prévu, l'e.i il a un champ, un getter, droit equals, hashcode et component1. Le hic, c'est que toString et copy sont bizarre:

println(Test(1))          //prints: Test(_value=1)
Test(1).copy(_value = 5)  //<- weird naming

De résoudre le problème avec toString vous pouvez redéfinir par les mains. Je ne connais pas de moyen pour régler le paramètre de nommage, mais de ne pas utiliser data à tous.

Ce qui semble être une (parmi d'autres) inconvénients gênants de Kotlin.

Il semble que la seule solution raisonnable, ce qui maintient la compatibilité descendante de la classe est de le convertir en une classe ordinaire (pas un "données" de la classe), et de mettre en œuvre à la main (avec l'aide de l'IDE) les méthodes: les méthodes hashCode(), equals(), toString(), copy() et componentN()

class Data3(i: Int)
{
    var i: Int = i

    override fun equals(other: Any?): Boolean
    {
        if (this === other) return true
        if (other?.javaClass != javaClass) return false

        other as Data3

        if (i != other.i) return false

        return true
    }

    override fun hashCode(): Int
    {
        return i
    }

    override fun toString(): String
    {
        return "Data3(i=$i)"
    }

    fun component1():Int = i

    fun copy(i: Int = this.i): Data3
    {
        return Data3(i)
    }

}