android10 / android10/Android-CleanArchitecture
Mapper and the GC
- Dominant language
- Java
- Stars
- 15.5k
- Forks
- 3.3k
- PR merge metrics
- No merged PRs in 30d
Description
I really liked how you organized this architecture, so I tried to implement it myself.
It was going fine at first, but when I came across large JSON objects trees I started to think if it's a bad practice to use the Mapper pattern.
It's a good practice avoid object instantiation, specially in Android, where the GC runs in the UI Thread.
I'm using GSON for JSON parser and with that some of my objects have a lot of children objects in this properties tree. A single object request instantiate a bunch of other objects just to go from Data to Presentation using the Mapper Pattern. But practically it could be achieved with, I don't know, 1/3 of the objects.
A simple solution that I thought, was to transform Model Domain classes into Interfaces, with this solution I removed one unnecessary instantiation, but I still kept the Model contract and flexibility for Data Entities.
In Kotlin it's very easy do that, but it could be done in Java as well.
Here follow some simple snippets
``` kotlin
interface User {
val id: Long
val uuid: String
}
class UserNetworkEntity(val userId: Long, val userUuid: String) : User {
override val id: Long
get() = userId
override val uuid: String
get() = userUuid
}
class UserRealmEntity(val data_id: Long,val data_uuid: String) : User {
override val id: Long
get() = data_id
override val uuid: String
get() = data_uuid
}
class UserRepository {
fun getUser(): Observable {
return Observable.just(UserDataSource().getUser())
}
}
class UserDataSource {
fun getUser(): UserNetworkEntity {
return UserNetworkEntity()
}
}
```
What problems this implementations brings? We can still achieve performance with the Mapper Pattern?
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.