Android code refactoring: clean code usecases
Tags: android, mobile, kotlin, tristan
Published: 2023-02-06 16:14:58

###Introduction
- In this series we are going to be talking about code refactoring, which is considered a more intermediate topic. So if you never have heard about UseCases or the Android clean code architecture, then this tutorial series might not be for you. 
- Also, I would like to point out that these patterns are really more like guide lines and not strict rules that you must abide by.

###Resources
- I found these refactoring patterns in the [Greenstand Android](https://github.com/Greenstand/treetracker-android) GitHub repository. Specifically, I looked at these 3 files:

**1)** [UsesCases Abstraction](https://github.com/Greenstand/treetracker-android/blob/e2a9a9b27c661fd221fd7e1c036299f60200d2c9/app/src/main/java/org/greenstand/android/TreeTracker/usecases/UseCase.kt)

**2)** [No parameters UseCase](https://github.com/Greenstand/treetracker-android/blob/23d0d21536884193666ccda95923ae0cd1cb7028/app/src/main/java/org/greenstand/android/TreeTracker/usecases/SyncDataUseCase.kt)

**3)** [Multiple parameters UseCase](https://github.com/Greenstand/treetracker-android/blob/41786fa2a16e6e28a708ba6c5172b5842649efb7/app/src/main/java/org/greenstand/android/TreeTracker/usecases/CreateLegacyTreeUseCase.kt)

### 1) UsesCases Abstraction
- So the UseCase abstraction looks like this:
```
abstract class UseCase<in Params : Any, out Result> {

    abstract suspend fun execute(params: Params): Result
}
```
- Just a little reminder, all Abstract classes in Kotlin are open by default and can not be instantiated but only inherited. We use this abstract class to implement the same behaviour across related UseCase objects, which allows us to establish a `is a` relationship.
- The next thing I should point out is the `in` and `out` operators. Which are called `contravariant` and `variance` annotations. Without diving too deep into generics, we can understand that the `in`(contravariant) operator means it can only be consumed and never produced(not allowed as a return type). The `out`(variance) operator means it is to be only produced(used as a return type)


### 2) No parameters UseCase
- So if we start with a UseCase code like:
```
class LogoutUseCase constructor(
    private val authRepository: AuthRepository
) {
    suspend fun invoke():Boolean{
        return authRepository.signUserOut()

    }
}

```
- Then we can implement our Abstract UseCase, resulting in:
```
class LogoutUseCase constructor(
    private val authRepository: AuthRepository
):UseCase<Unit,Boolean>() {

    override suspend fun execute(params: Unit): Boolean {
        return authRepository.signUserOut()
    }
}
```
- So lets talk about the `Unit` class being used in `execute(params: Unit)`. `Unit` type fulfills the same function as Java's `void`. But what makes the two different is that `Unit` is a full fledged type and unlike void, it can be used as a type argument. Which makes it useful when combined with generics. To call the `execute()` method we would do so like this:

```
logoutUseCaseInstance.execute(Unit)
```
- We are able to do this with `Unit` because it is a singleton and returns the [Unit](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-unit/) object


### 3) Multiple parameters UseCase
- Now we are going to understand how to use this pattern when we are faced with multiple parameters. So starting with a class like:
```
class CreateUserUseCase constructor(
    private val database:DatabaseRepository
){

    suspend operator fun invoke(email:String, username:String):Flow<Response<Actions>>{
        return database.createUser(email, username)
    }
}

```
- Then when we implement our pattern, we get:
```
data class CreateUserParams(
    val email: String,
    val username: String,
)

class CreateUserUseCase constructor(
    private val database:DatabaseRepository
):UseCase<CreateUserParams,Flow<Response<Actions>>>(){


    override suspend fun execute(params: CreateUserParams): Flow<Response<Actions>> {
        return database.createUser(params.email, params.username)
    }
}

```
- Notice the `CreateUserParams` class, this is how we are dealing with the problem of multiple parameters. By creating a data class we are able to handle any number of parameters which are needed.

- While this might seem like extra work, what this refactoring really does is makes our code more readable and predictable. 


###Conclusion
- Thank you for taking the time out of your day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on [Twitter](https://twitter.com/AndroidTristan).