@User uploaded a file: Untitled

I'm wondering whether I'm kind of abusing how easy it is to put multiple classes in a file in Kotlin. The API I'm working with has basically four important classes, each one of which of which has somewhat different fields based on what endpoint I'm calling (either extra or less fields, not like one field suddenly turns from string to int). It also has a bunch of other smaller ones. So I'm curious as to what the sort of 'best practice' would be. Currently each endpoint has its own

Response

class, containing everything for that specific endpoint, so each class has exactly what it needs, which unfortunately causes a lot of duplicate code. Would it be better to just create single classes for the most important ones, put every possible field in there, and just reuse this? Below is the

Response

for the newest endpoint I just added.

@User uploaded a file: TrackInfoResponse.kt

One thing to note is that each endpoint and response class also have a corresponding

model

class and a mapper that maps the response to a model. This model class is basically just a somewhat simplified version which is used on the presentation side, removing complexity and nesting. For example a list of images with size fields 'small', 'large', 'extralarge', will then just be

imageUrlSmall

and

imageUrlLarge

directly in the model class.

So I guess in that case I could just write four large classes for track, album, tag and artist and have the mapper just ignore fields that are not relevant for that call.

Or am I just overthinking this

@frank This is how I do it too. Except for putting model into the same file / package.

Having response separate from model is a way to extract communication issues with backend devs into a single place. 🙂

I am looking for good reference (project/article...) how to that properly structures Retrofit Services

What do you mean?

@mg6maciej That's also the part I like! Makes it a lot easier to separate backend and frontend in the application. My primary issue however is duplicate classes within these responses. See the snippet I'll post below. The four classes at the top show exactly what the API returns in different endpoints, with a lot of duplicate lines. However, I could technically replace these with

GeneralArtistEntity

, but I'm wondering whether this is a good idea.

@User uploaded a file: Artist classes

Doesn't seem like a good idea.

Because that way I'd be moving knowledge about responses from the response classes to the mappers I guess? They're basically just 'dumb' atm, copying anything they encounter into a different structure in the model

I would keep them separate and adhere to: inherit behaviour, not state.

Hmm.

But you have basically the same "thing" / entity from all the endpoints?

Just with some endpoints return objects with missing data?

Then I would definitely merge them on the service layer and maybe create different models from them for use in presentation.

merge -> create one bigger, model

Well, I'm using a music API. One endpoint might return information about an album. This basically has three nested objects: Album (almost the full object), list of tracks (for example name, mbid and number on the album) and the artist (for example name and mbid). Another endpoint would be getting information for an artist, which would return a full artist object and smaller album and track objects.

So it's basically three main objects: Artist, Track and Album, and some other smaller ones

I am indeed merging them in the presentation layer

Yes, so Artist would be one entity with nullable types for fields received from API.

Unless all always have given data, like name.

Yes, the snippet I posted above shows the situation for artist

In that case all of them have mbid, name and url

So

GeneralArtistEntity

is what I would receive from API and then most likely model for that, or few models, but that depends on how this data is used on different screens.

If you never have data from 2 endpoints used in the same place on single screen, then a few models are ok.

If you had single model, you would always have some fields nullable.