Level Up Your Kotlin: Unwrapping the Decorator Pattern with Modern Flair

 Move beyond bloated constructors and messy flags with idiomatic functional decorators and extension functions.

Decorator Pattern

Ever found yourself with a class whose constructor just keeps growing? Or maybe you’ve added features that required modifying stable, unit-tested code? You’ve likely encountered the “Ever-Expanding Constructor” syndrome — the perfect use case for the Decorator Pattern.

In this guide, we’ll move from a messy, flag-based architecture to the classic “Gang of Four” structure, and finally to a modern Kotlin implementation that feels like magic.

The Problem: Feature Creep & “The God Constructor”

Imagine you’re building a reporting tool. It starts simple, but soon the business asks for timestamps, unique tracking IDs, and user metadata.

// ⚠️ ANTI-PATTERN: The "God Constructor"
class ComplexReportGenerator(
    private val includeTimestamp: Boolean = false,
    private val includeUniqueId: Boolean = false,
    private val includeUserName: Boolean = false,
    private val clock: Clock = Clock.systemDefaultZone() // Dependency bloat: why is this here if flag is false?
) {
    fun generate(data: String): String {
        var report = "Report: $data"
        if (includeTimestamp) report = "${LocalDateTime.now(clock)} - $report"
        if (includeUniqueId) report = "[ID:${UUID.randomUUID().toString().take(8)}] $report"
        return report
    }
}

Why this fails:

  • Violates Open/Closed Principle: You must modify this class every time a new feature is requested.
  • Dependency Pollution: The generator needs to know about Clock even if timestamps are disabled.
  • Fragile: Changing logic for one flag might accidentally break another in the same generate block.

1. The Traditional Way: Gang of Four (GoF)

The classic solution is to wrap the original object in a “Decorator” that implements the same interface.

interface ReportGenerator {
    fun generate(data: String): String
}

class BasicReportGenerator : ReportGenerator {
    override fun generate(data: String): String = "Report: $data"
}

// The Base Decorator delegates all calls to the wrapped object
abstract class ReportDecorator(protected val inner: ReportGenerator) : ReportGenerator {
    override fun generate(data: String): String = inner.generate(data)
}

class TimestampDecorator(inner: ReportGenerator, private val clock: Clock) : ReportDecorator(inner) {
    override fun generate(data: String): String = "${LocalDateTime.now(clock)} - ${super.generate(data)}"
}

The Verdict: Structurally perfect, but leads to “Class Explosion.” You end up with a dozen files just to add a few string prefixes.

2. The Kotlin Way: Functional Decorators

Kotlin allows us to treat the Decorator Pattern as a form of Function Composition. By using fun interface and extension functions, we layer behavior from the outside without the hierarchy overhead.

// 1. The Component as a Functional Interface
fun interface ReportGenerator {
    fun generate(data: String): String
}

// 2. Concrete Component
fun basicReportGenerator() = ReportGenerator { data -> "Report: $data" }

// 3. Decorators as Extension Functions
fun ReportGenerator.withTimestamp(clock: Clock): ReportGenerator = ReportGenerator { data ->
    "${LocalDateTime.now(clock)} - ${this.generate(data)}"
}

fun ReportGenerator.withUniqueId(): ReportGenerator = ReportGenerator { data ->
    "[ID:${UUID.randomUUID().toString().take(8)}] ${this.generate(data)}"
}

Creating the Final Object (Fluent API)

val clock = Clock.systemDefaultZone()

val finalGenerator = basicReportGenerator()
    .withUniqueId()
    .withTimestamp(clock)

println(finalGenerator.generate("Sales Figures"))
// Output: 2023-10-26T10:46:00 - [ID:e5f6g7h8] Report: Sales Figures

Pro Tip: Decorators apply in reverse order of invocation (like mathematical function composition). In the example above, withTimestamp wraps the result of withUniqueId.

Deep Dive: Senior Credibility

Is this “Real” Decorator or just Functional Trickery?

It’s a true Decorator. It wraps an object and enhances behavior while maintaining the interface. Kotlin simply uses Dependency Locality — passing the Clock only to the decorator that needs it, rather than the base generator.

Testing: Isolated and Predictable

Testing functional decorators is trivial because they are stateless transformations.

@Test
fun `adds timestamp correctly`() {
    val fixedClock = Clock.fixed(Instant.parse("2025-12-17T10:00:00Z"), ZoneOffset.UTC)
    val generator = basicReportGenerator().withTimestamp(fixedClock)

    val result = generator.generate("Test Data")
    assertEquals("2025-12-17T10:00:00 - Report: Test Data", result)
}

Performance & Thread Safety

  • JVM Reality: Each decorator creates a lightweight lambda. Thanks to JIT inlining, this is almost never a bottleneck outside of extreme high-frequency loops.
  • Immutability: These decorators are pure transformations. They don’t maintain internal state, making them inherently thread-safe.

Frequently Asked Questions (FAQs)

Doesn’t this make debugging harder?

Stack traces will show lambdas, but because the logic is encapsulated in small extension functions, finding the source of a bug is usually faster than digging through a 500-line “God Class.”

What’s the difference between this and Strategy?

Strategy replaces internal logic. Decorator wraps the whole object to add or modify behavior transparently.

Is this just Middleware?

Yes! Middleware is simply the Decorator Pattern applied to the lifecycle of a request.

Challenges to Master the Pattern

  • The Placement Challenge: How would you design your decorators so that the Timestamp always appears at the start of the string, regardless of whether it's called first or last in the chain?
  • The Error Decorator: Create a .withErrorHandling() decorator that catches exceptions in the generation process and returns a fallback message.

If you find my content useful, feel free to support my work here. Every contribution is greatly appreciated! 🙏

Comments

Post a Comment

Popular posts from this blog

Stop Writing Massive when Statements: Master the State Pattern in Kotlin

Image
 Tame Your Codebase with Elegant, Scalable, and Type-Safe State Machines Do you manage complex objects that change their behavior dramatically based on their internal status? If so, you’ve likely battled a common foe: the sprawling  when  statement that haunts every method in your class. It looks something like this: fun handleAction () { when (state) { State.A -> { /* logic for A */ } State.B -> { /* logic for B */ } State.C -> { /* logic for C */ } // ... and the list keeps growing! } } Every time you add a new state (e.g.,  State.D ), you have to hunt down and update  every single function  with a new case. This is a maintenance nightmare, a direct violation of the  Open/Closed Principle  (OCP), and a major code smell. Your logic is scattered by  action  when it should be grouped by  state . The solution? The  State Pattern . And with modern Kotlin, we can implement it w...
Read more

Coroutines & Flows: 5 Critical Anti-Patterns That Are Secretly Slowing Down Your Android App

Image
 Stop sneaky performance killers. Spot and fix Kotlin issues that cause crashes, memory leaks, and laggy UIs. Coroutines and Kotlin Flows are the bedrock of modern asynchronous programming on Android. They allow us to write clean, sequential-looking code that manages complex background operations, network calls, and database transactions. But power comes with responsibility. Many developers, despite using Coroutines daily, unknowingly introduce subtle mistakes —  anti-patterns  — that lead to memory leaks, silent crashes, data loss, and UI jank. Based on insights from top-tier Android development, here are five critical Coroutine and Flow anti-patterns you must identify and fix today, plus one bonus pitfall I often see in code reviews. 1. The Main Thread Trap: Heavy Work in  viewModelScope When you launch a coroutine inside a  ViewModel  using  viewModelScope.launch { ... } , where do you think that work runs by default? The  Main Thread ! If your...
Read more

Code Generation vs. Reflection: A Build-Time Reliability Analysis

Image
 Choose compile-time safety over runtime simplicity to ensure better R8 optimization, avoid reflection issues, and cut production crashes. The world of Android development offers numerous ways to achieve the same goal, but not all paths are created equal. When it comes to tasks like dependency injection, JSON parsing, or database interaction, two prominent approaches stand out: Code Generation and Reflection. While reflection might seem appealing for its initial simplicity, a deeper dive reveals that   Code Generation offers superior build-time reliability and R8 compatibility , making it the more robust choice for production-ready applications. The Allure of Reflection: Simplicity at a Cost Reflection, at its core, allows a program to inspect and modify its own structure and behavior at runtime. This dynamic nature can be incredibly powerful, enabling libraries to work with classes and their members without needing to know them at compile time. Example: A (simplified) Reflect...
Read more