DEV Community: Mikhail

How to apply SRP (Single Responsibility Principle) in Kotlin + Spring Boot project

Mikhail — Mon, 06 Jan 2025 10:08:04 +0000

How you know, the SRP is about "a class should have only one responsibility, do only one job, have only one reason for change, etc.". This principle is fundamental to writing clean, maintainable, and testable code. I read it in each book contains SOLID description.
But what does it mean: "one responsibility, one job, one reason for change"? Which of my own classes or those in the public libraries follow SRP and which do not?
For example, is LnkedList following SRP or not? Actually no. This class violates SRP because it has multiple responsibilities:

adding elements to the list,
removing elements from the list,
managing the list's head and tail,
provides some queue methods,
do many other things.

But I didn't find an answer to this fundamental question in many books for beginner developers.
I think it's a million-dollar mistake - the reason why we have thousands of programmers who know the description of the SRP but don't know what it should look like in code. These programmers write complicated and ugly code that is difficult to read, understand, test, and change.
You may have heard of "spaghetti code" or seen it. If not, I'll show it to you:

@Service
class SomeService {

    fun f1() {
        ...\\ if-else blocks
        val v2 = f2()
        ...
        return v1
    }

    fun f2() {
        ...\\ if-else blocks
        val v3 = f3()
        ...
        return v2
    }

    fun f3() {
        ...
        return v3
    }
}

This class has three public functions that call each other and can be called from outside the class. If you want to modify one of these functions, you need to search for all the places it is used. And these places may look like the SomeService class...
Now, you understand how violating SRP can ruin your project from its begin. What can you do to avoid SRP violations? Only two rules need to be followed:
1) class should have only one public function

@Service
class DoSomeBusinessFunction(
    private val doCommonFunction: DoCommonFunction, 
) {

    fun execute() {
         ...
         val v2 = doOtherBusinessFunction.execute()
         val v4 = f4(v2)
         ...
         return v1
    }

    private fun f4(v2: Value2) {
         ...
         return v4
    }
}

@Service
class DoOtherBusinessFunction(
    private val doCommonFunction: DoCommonFunction, 
) {

    fun execute() {
         ...
         val v3 = doCommonFunction.execute()
         ...
         return v2
    }
}

@Service
class DoCommonFunction {

    fun execute() {
         ...
         return v3
    }
}

2) If you want to create a function that behaves differently for different business scenarios, forget about trying to modify it and follow the "KISS" principle by using "magical" shortcuts like Ctrl + C, Ctrl+ V. Create a new class that has a new public function with a new behavior:

@Service
class DoSomeBusinessFunctionV1 {
    private val doOtherBusinessFunction: DoOtherBusinessFunction,
) {

    fun execute() {
         ...
         val v2 = doOtherBusinessFunction.execute()
         ...
         return v1
    }
}

@Service
class DoSomeBusinessFunctionV2 {
    private val doCommonFunction: DoCommonFunction,
) {

    fun execute() {
         ...
         val v3 = doCommonFunction.execute()
         ...
         return v1
    }
}

This approach keeps your code clean and gives you the following benefits:
1) simplifies code reading and understanding
2) simplifies unit tests writing
3) simplifies code changing
4) teaches junior developers to understand programming principles and apply them in practice.

How to implement JaCoCo in Kotlin + Spring Boot + Gradle project

Mikhail — Sat, 04 Jan 2025 09:12:47 +0000

JaCoCo is a free code coverage library for Java, created by the EclEmma team. It is based on the lessons learned from using and integrating existing libraries for many years.
To use JaCoCo in your project you need to do:

Add the JaCoCo plugin to the plugins section of the build.gradle.kts file in the root directory of your project.

plugins {
    ...
    id("jacoco")
}

Add JaCoCo's jacocoTestReport task and jacocoCoverageVerification task as finalizing a Test task. JaCoCo based on Java byte code and therefore you need to compile the bytecode of your application and test classes before running it.

tasks.withType<Test> {
    ....
    finalizedBy(tasks.jacocoTestReport, tasks.jacocoTestCoverageVerification)
}

Configure the violation rules for the jacocoVerificationCoverage task.

tasks.jacocoTestCoverageVerification {
    violationRules {
        rule {
            limit {
                minimum = "0.6".toBigDecimal()
            }
        }
    }
}

To run JaCoCo, start gradle test task or gradle check task. This will build byte code for your application and test classes and run the tests. At the end of the Test task, JaCoCo will run its tasks, checking test coverage.

The jacocoCoverageVerification task will print a report in the console.

> Task :jacocoTestReport
> Task :jacocoTestCoverageVerification FAILED
[ant:jacocoReport] Rule violated for bundle template: instructions covered ratio is 0.1, but expected minimum is 0.6
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':jacocoTestCoverageVerification'.
> Rule violated for bundle template: instructions covered ratio is 0.1, but expected minimum is 0.6
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 13s

The jacocoTestReport task will create a test report in HTML format that you can find in the project's built directory.

The entire code is available on GitHub.

How to implement detekt in Spring Boot + Kotlin + Gradle project

Mikhail — Mon, 30 Dec 2024 14:11:53 +0000

Detekt is an open-source static code analyzer developed by the Kotlin community. It's flexible and easy to extend with custom rules, which helps you track anti-patterns and fix them in your code base.

Integration

To use detekt in your project, you need to follow a few simple steps:
First, enable the detekt plugin in the build.gradle.kts file at the root of the project. You can find the plugin version you need here.

plugins {
    id("io.gitlab.arturbosch.detekt") version "1.23.7"
}

Then, download the rules configuration from the detekt GitHub repository and place it in your project directory or wherever you prefer.
Next, set the path to the detekt configuration file in build.gradel.kts file.

detekt {
    basePath = projectDir.path
    config.setFrom("detekt/config.yml")
    buildUponDefaultConfig = false
    parallel = true
}

Finally, learn about detekt rules and customize the configuration as needed.
Some custom detekt configurations for example:
Disable rule:

SomeProperty:
  active: false

Disable rule for files and folders.

SomeProperty:
  active: true
  excludes: ['**/test/**', '**/*SomeClass*']

How to run

There are several ways to run detekt analyze.
Execute cli command in the root directory of your project

gradle detekt

gradle check

You can also start detekt in the gradle menu of IntelliJ IDEA:

Examples of detekt output

Failure report in the terminal:

terminal:~/IdeaProjects/template$ gradle detekt
Starting a Gradle Daemon (subsequent builds will be faster)

> Task :detekt FAILED
/home/mikhail/IdeaProjects/template/src/main/kotlin/ru/epatko/template/Application.kt:10:29: In most cases using a spread operator causes a full copy of the array to be created before calling a method. This may result in a performance penalty. [SpreadOperator]

FAILURE: Build failed with an exception.

Success report in the terminal:

terminal:~/IdeaProjects/template$ gradle detekt

BUILD SUCCESSFUL in 780ms
1 actionable task: 1 executed

You can also find the detekt report with various code metrics in the <project-root-directory>/build/detekt/detekt.html file.

Conclusion

I hope that these simple steps, outlined in the configuration and usage instructions, will allow you to quickly integrate detekt into your projects and use its capabilities to improve the quality of your code and maintain it.
The entire test project is available on GitHub.

We no need write Java in Kotlin

Mikhail — Sat, 28 Dec 2024 13:08:57 +0000

One day, I had a lively discussion with colleagues of mine about using custom types as DTO model ID. I wanted to share some details of it with you.
Let's imagine we have an entity corresponding to a table with the same name in a database.

@Table(value = "employee")
data class EmployeeEntity(

    @Id
    val id: Long? = null,

    @Column("name")
    val name: String,
)

I used to describe the DTO model that corresponds to this entity something like this:

data class Employee(
    val id: Long,
    val name: String,
)

The same model written using the discussed approach with custom ID:

data class Employee(
    val id: Id<Employee>,
    val name: String,
) {
    // from 100 lines of code to make it work
}

These two models differ in the id field. In the first one, the id is a simple Long. In the second one, it's a custom type parameterized by the entity type (such as an Ouroboros). Here's how this custom Id type might look:

class Id<T : Any> private constructor(
    private var _value: Long?,
) {
    // from 100 lines of boiler plate code 
    // to override standard functions,
    // implement builders and etc.
}

Besides writing 100+ lines of code for this custom ID to work, there are at least another 100+ lines of code implementing factories and builder methods to convert the model to an entity and vice versa.
The main question in our discussion was whether it's better (more effective) to use val id: Long or val id: Id<Employee>.

Advantages of the first approach (val id: Long):

it's Kotlin,
it's simple and easy to understand,
no unnecessary code that doesn't carry business logic. Less code means less mental load, faster feature development, fewer mistakes, and less testing.

Cons:

you might accidentally pass the wrong ID to a function. For example:

val employee = getEmployeeById(employeeId = organization.id)

fun getEmployeeById(employeeId: Long) {...}

this approach might seem too simple for some.

An advantage of the second approach (val id: Id<Employee>):

it's some harder to make mistakes. Actually, this was the main argument of my opponents: you can't even trust yourself, everyone can make mistake,
a dose of dopamine for anyone who missed complexity in their project.

Cons:

it's still possible to accidentally make a mistake

val employee = getEmployeeById(
    employeeID = Id.from(organization.id)
)

fun getEmployeeByID(id: Id<Employee>) {...}

this is not Kotlin style code. Perhaps my colleagues used this approach in Java code. And it was necessary in their Java projects. But Kotlin is the language designed to make complex things easy, not vice versa. To avoid accidentally confusing parameters, Kotlin allows passing parameters by name:

val employee = getEmployeeById(employeeId = 1L)

So, what's the verdict?
If you can accidentally make a mistake using both approaches, then why write more code to use a custom type as an ID?
Kotlin is a well-designed and elegant language. Dragging the baggage of Java habits into Kotlin code is like voluntarily abandoning the new and efficient for the old and clunky.

Using spring-boot-starter-validation library with Kotlin

Mikhail — Sat, 28 Dec 2024 09:12:57 +0000

If you're using Spring Boot, you may need to validate your incoming requests. The spring-boot-starter-validation library is a good choice. However, when using Kotlin types, there is a specific consideration. This article will show you how to effectively validate JSON request body in Spring Boot with Kotlin.

Project Structure
Let's start with a simple Spring Boot project with Kotlin. The project includes two endpoints: one for a nullable type field in JSON request body and one for a non-nullable type field.

@RestController
class TemplateController {

    @PostMapping("/nullable")
    fun createNullable(
        @Valid @RequestBody request: CreateNullableRequest,
    ): String = "Hello, nullable World!"

    @PostMapping("/non-nullable")
    fun createNonNullable(
        @Valid @RequestBody request: CreateNonNullableRequest,
    ): String = "Hello, non nullable World!"
}

Both functions use @jakarta.validation.Valid annotation and @jakarta.validation.constraints.NotBlank annotation on the fields.

data class CreateNullableRequest(

    @field:NotBlank(message = "May not be blank")
    val name: String? = null,
)

data class CreateNonNullableRequest(

    @field:NotBlank(message = "May not be blank")
    val name: String,
)

The project also has the ErrorHandlerController for intercepting and handling validation errors.


@RestControllerAdvice
class ErrorHandlerController {

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(MethodArgumentNotValidException::class)
    fun handleValidationException(ex: MethodArgumentNotValidException): Errors = Errors(
        errors = ex.bindingResult
            .fieldErrors
            .map {
                Error(
                    key = it.field,
                    message = it.defaultMessage ?: "Validation error"
                )
            }
    )
}

Test Requests
Let's send the same requests to both endpoints, setting name field in the JSON request body to null and compare the responses.
Non nullable endpoint:

Request:
POST http://localhost:8080/non-nullable
Content-Type: application/json
{ "name": null }

Response:
HTTP/1.1 400 
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sat, 28 Dec 2024 08:09:56 GMT
Connection: close
{
  "timestamp": "2024-12-28T08:09:56.409+00:00",
  "status": 400,
  "error": "Bad Request",
  "path": "/non-nullable"
}

The response includes error code 400 (Bad Request) and JSON request body with some information. This response is not very useful because it doesn't provide specific details about the validation error.
Nullable endpoint:

Request:
POST http://localhost:8080/nullable
Content-Type: application/json 
{ "name": null }

Response:
HTTP/1.1 400 
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sat, 28 Dec 2024 08:08:06 GMT
Connection: close
{
  "errors": [
    {
      "key": "name",
      "message": "May not be blank"
    }
  ]
}

The response also includes error code 400 (BadRequest). But the JSON body includes more specific information about the validation error, which is much more helpful for debugging and understanding the issue.
To get a more understandable error message from a non nullable endpoint, let's add a function to handle general exceptions in ErrorHandlerController.

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler(Exception::class)
    fun handleGeneralException(ex: Exception): Errors = Errors(
        errors = listOf(
            Error(
                key = ex.javaClass.simpleName,
                message = ex.message ?: "unknown error"
            )
        )
    )

If you send an invalid request to a non-nullable endpoint again, you will receive the response:

Request:
POST http://localhost:8080/non-nullable
Content-Type: application/json
{ "name": null }

Response:
HTTP/1.1 500 
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sat, 28 Dec 2024 08:28:26 GMT
Connection: close

{
  "errors": [
    {
      "key": "HttpMessageNotReadableException",
      "message": "JSON parse error: Instantiation of [simple type, class ru.epatko.template.model.CreateNonNullableRequest] value failed for JSON property name due to missing (therefore NULL) value for creator parameter name which is a non-nullable type"
    }
  ]
}

In the response, you can see error code 500 (Internal Server Error) and the error message. Although this response looks understandable to humans, it will be less understandable for another application that sends a request to our endpoint. Additional effort will be needed so that the app can parse this response as a "Bad Request" and handle it correctly.

Conclusion
As you can see, the difference between non nullable and nullable endpoints is that the application attempts to parse the JSON request body before validating the fields of the received object. If the body cannot be parsed, it throws HttpMessageNotReadableException. This is because Kotlin does not allow creating a CreateNonNullableRequest object with field name = null.
If you want to improve the consistency and clarity of your API, you should use nullable Kotlin types to validate the incoming JSON request body.
The entire project's code is available on GitHub.