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.
Avoir une logique d'entreprise qui crée de l' 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.
-
N'utilisez pas de data class
. Utilisez un régulier, class
et votre IDE de générer de l' 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()
}
}
-
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 les 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 hashCode
s, 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 altéré il / elle ne fonctionne pas comme prévu (c'est à dire que cette approche ne fonctionne pas correctement dans un Map
ou Set
).