0

I want to perform some operations on data class fields before accessing them and I am confused about which approach I should follow.
I want to write code so that it makes sense to everyone and follows by experts so I want to know Is it good to make data class fields private and only let them access public fields by performing some operation.

data class BatteryDemo(
    private val _level: Int,
    private val _temperature: Int,
    private val _voltage: Int,
) {
    val level get() = _level.toString()
    val temperature get() = _temperature.toString()
    val voltage get() = _voltage.toString()

}

Or

Make the fields of data class public and let the operation be performed in the interface using Interfaces Inheritance and implement that interface in the data class. https://kotlinlang.org/docs/interfaces.html#properties-in-interfaces

interface IBatteryProfileDetailed {
    val _level: String
    val temperatureCelsius: String
}

interface IBatteryProfile : IBatteryProfileDetailed {

    val level: Int
    val temperature: Int
  
    override val _level: String
        get() = level.toString()

    override val temperatureCelsius: String
        get() = temperature.div(10).toString()

}

data class BatteryProfile(
    override val level: Int,
    override val temperature: Int,
    .... other fileds .....
) : IBatteryProfile

Which is the best approach I should follow? Or there is another best approach than suggest me.

1
  • 2
    If you are not going to use interfaces for polymorphism, dependency management, or to reuse abstract logic, don't use them (and if you don't know what those are, don't use them for now - wait until you develop a better understanding). Nov 2 '21 at 15:36
2

In my point of view private variables with getter and setter and interfaces are two different levels of encapsulation.

With private variables and the use of getter and setter methods, you can change your implementation of the class without that the "user" (the code that uses your class) has to change anything.
That means you can add/change validation, add logging or other stuff and (as long as the API does not change) the user will not even realize that.

Or to say it differently:
The code which uses your class does not "know" that their is no code executed when they try to read or write a variable.

With an interface between your class and the user, the user does not know THE CLASS itself. The using code only knows that their will be an instance which looks like this. But does not know the class itself.
This allows to replace the whole CLASS easily, as long as the new class still follows the interface.

So, my personal approach: I personally do not like using getter and setter in all cases. So, if the getter and setter only pipes the data through to the private variable, without DOING anything, then i omit it. I do that, because on one side, those getter/Setter makes the code harder to read and on the other side, most languages nowadays allow to later add getter and setter without having to change the code that "uses" the variable. Therefore if i need to add code later, then i can easily switch to getter/setter.

On the other side INTERFACES are quite cool. Combined with dependency injection it makes unit testing MUCH easier. And they help to break dependency circles, which can be really annoying. :-)

So long story short:
Interfaces and private variables with getter and setter are for different purposes. Depending on your UseCase you have to decide which is more helpful (or if you should use both).

4
  • my use case is that from the Broadcast receiver I want to pass temperature Fahrenheit (°F) to the data class but my UI needs to show the temperature in the form of Celsius (°C) or vice versa. So where to put this logic? I know is that such logic should be placed in the data class but if I do so I have to make data class field temperature private because there is no use of it in UI my UI needed only temperature Celsius. But I have not seen a data class with private fields and personally do not like So I decide to shift to the interface but don't know which is best.
    – Lokik Soni
    Nov 2 '21 at 8:44
  • So you need a way to set the Fahrenheit temperature and one to get the Celsius temperature. No need for reading Fahrenheit and writing Celsius?
    – JanRecker
    Nov 2 '21 at 12:41
  • No, I don't need this, One more example of my use case is that pass battery level of type Int to the data class, and my UI required it as a string with concatenation %. You can understand it like data passed from Broadcast to data class is not required by UI as it is I need to modify it or perform some operation o it. So where to put such logic?
    – Lokik Soni
    Nov 2 '21 at 13:32
  • So if its "just" converting, then i would use extra methods. Having the temperature stored in Fahrenheit (as private) and methods to read or write the value as Celsius. I would also add methods for Fahrenheit, just that the API is unified. And not accessing Fahrenheit values over the variable and celsius values over methods. This also "hides" your implementation, instead of creating a 1to1 picture of your class content in your API. For Battery Level i have a SETTER, no GETTER, and a specific method (String). I don´t like, a setter that expects a different format then the getter.
    – JanRecker
    Nov 2 '21 at 15:15
1

My general preference is "getters and setters." For a few practical and maybe philosophical reasons.

• "Philosophically," I don't think that "how it works" ever belongs in an interface definition.

• *"Getters and Setters," even when they are just one line, serve both to document that this access to an otherwise-private value is taking place, but also (and, IMHO, most importantly ...) to put the actual effects of it into "your court." That is to say, "in this source-file and nowhere else."

Please don't make me look elsewhere – don't make me guess – don't make me feel uncertain. Don't let me write a bug.

And, if ever in the future I need to change this behavior, please enable me to do it in only one place, and to be confident that I can now close the ticket. ("I really don't like surprises, because they usually happen at one o'clock in the morning.")

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.