How do you choose adding methods to dto/dao vs add...

# codingconventions

[George]

How do you choose adding methods to dto/dao vs adding extension methods? My understanding is that everything should be an extension. But for some reason it feels like I am missing some good cases where it makes sense to add methods inside the dto/dao.

Ps: I am not referring to complex business logic functions, these should reside elsewhere.

[CLOVIS]

Have you read https://elizarov.medium.com/extension-oriented-design-13f4f27deaee?

[George]

Yep, it’s a good one. I guess if we think dtos/entities as type of datas that should only contain "data" then yea we should only use extension functions.

I suppose the diff here is only semantically as there is no actually diff in code if we placed them inside the class.

In roman’s example, he used a classic data type, which in those the wins are big and obvious and not only semantically. That’s why I thought I should ask here for more opinions.

[Jørund Amsen]

I've always prefered to split classes into "doers" and "data", where data classes have minimal functionality. This also applies to extension functions, usually if I can solve it with a pure input/output function that works on and returns a copy of the data class(if needed) I'd rather do that than make extension functions.

A classic example would be mappers to dtos for example

data class Person(val name:String)
data class PersonDto(val name:String)

fun Person.toDto(): PersonDto {...}

fun toDto(person: Person): PersonDto {...}

val dtos = listOf(Person("Jerry")).map (::toDto)
val dtos2 = listOf(Person("Tom")).map { it.toDto() }

Im also a fan of function references so that might be simple preference. But input-output functions just feel more.. modular?

However when the arguments pile up, like romans example with string replace, and especially if it modifies the object I'm much more inclined to make it an extension function