Skip to main content

Command Palette

Search for a command to run...

Kotlin Code Smell 22 - Accidental Methods on Business Objects

Bloated Cars & Code: When Your Objects Carry Too Much Junk in the Trunk

Updated
2 min read
Kotlin Code Smell 22 - Accidental Methods on Business Objects
Y

I've started to work as a software engineer at 2014, however, I started to write code at high-school.

My first language was Assembly, but still, I fall in love with the possibilities to make the computer to do as you wish, shortly after that I started to write in C.

Later on I studied a practical engineering in electricity, and during this time discovered that I preferred much more writing code than design electrical components.

As a result of this understanding I decided to switch and study bachelor degree in computer science in Reichman university, where the focus was of the Java language.

Today I'm working at SumUp using Kotlin, SpringBoot & Micronaut, Cassandra and Kafka

Adding code for persistence, serialization, displaying, importing, and exporting to an object can lead to bloating its protocol and create unnecessary coupling.

Problem

  • Readability

  • Coupling

  • Maintainability

Solution

  1. Keep your objects clean by focusing on their core responsibilities.

  2. Decouple business objects from unrelated concerns.

  3. Separate accidental concerns: Move functionality related to a specific dedicated objects (e.g. Persistence, Formatting, Serialization).

  4. Keep the essential protocol of your objects concise and focused.

Examples

  • Persistence

  • Identifiers

  • Serialization

  • Formatting

Sample Code

Wrong

class Car(
    private val company: Company,
    private val color: Color,
    private val engine: Engine
) {
    fun goTo(coordinate: Coordinate) {
        move(coordinate)
    }

    fun startEngine() {
        engine.start()
    }

    fun display() {
        println("This is a $color $company")
    }

    fun toJson(): String {
        return "json"
    }

    fun updateOnDatabase() {
        database.update(this)
    }

    fun getId(): Int {
        return id
    }

    fun fromRow(row: Row) {
        database.convertFromRow(row, this)
    }

    fun forkCar() {
        // Concurrency is accidental
        ConcurrencySemaphoreSingleton.getInstance().forkCar(this)
    }

    // ...
}

Right

class Car(
    private val company: Company,
    private val color: Color,
    private val engine: Engine
) {
    fun goTo(coordinate: Coordinate) {
        move(coordinate)
    }

    fun startEngine() {
        // Code to start the engine - all logic was extracted
        engine.start()
    }

    // ...
}

Exceptions

  • In some cases, certain frameworks may force us to inject code related to unrelated concerns into our objects (e.g., identifiers). In such cases, it is advisable to explore better frameworks that allow for cleaner designs.

Conclusion

It is common to encounter business objects with mixed responsibilities. However, it is essential to consider the consequences and coupling that such designs can introduce.

Credits

Kotlin Code Smells

Part 15 of 36

In this series, we will see several symptoms and situations that make us doubt the quality of our development. We will present possible solutions. Most are just clues. They are no hard rules.

Up next

Kotlin Code Smell 21 - Mocking Business

Mockumentary: When Your Test Takes Acting Too Far

More from this blog

Yonatan Karp-Rudin | kotlin for backend developer skills | java for backend developer skills | SpringBoot | Tutorials

57 posts

Experienced Senior Software Engineer passionate about functional programming & Kotlin. Excels in app development, optimization, and team collaboration. Let's create something amazing!