You can mix OOP and functional programming in Kotlin by using objects/classes to model state, identity, boundaries, and domain concepts, while using functions/lambdas to model behavior, transformation, policies, and workflows.

Kotlin is especially good at this because it supports:

• Classes, interfaces, inheritance, encapsulation
• Data classes and sealed classes
• Lambdas and higher-order functions
• Immutability with val
• Extension functions
• Scope functions like let, run, also, apply
• Collection pipelines like map, filter, fold

1. Use OOP for domain models, FP for transformations

A common Kotlin style is to model entities with classes, then transform them using pure functions.

data class User(
    val id: Long,
    val name: String,
    val age: Int,
    val isActive: Boolean
)

fun User.canReceivePromotion(): Boolean =
    isActive && age >= 18

fun promoteEligibleUsers(users: List<User>): List<User> =
    users.filter { it.canReceivePromotion() }

Here:

• User is an OOP-style domain object.
• canReceivePromotion is behavior attached through an extension function.
• filter expresses functional transformation over a collection.

This avoids writing procedural loops like:

val result = mutableListOf<User>()
for (user in users) {
    if (user.isActive && user.age >= 18) {
        result.add(user)
    }
}

Prefer:

val result = users.filter { it.isActive && it.age >= 18 }

2. Prefer immutable objects

Functional programming favors immutability. In Kotlin, use val and data class.copy().

data class Order(
    val id: Long,
    val status: OrderStatus,
    val total: Double
)

enum class OrderStatus {
    Draft,
    Paid,
    Shipped,
    Cancelled
}

fun markAsPaid(order: Order): Order =
    order.copy(status = OrderStatus.Paid)

Instead of mutating the existing object:

class MutableOrder {
    var status: OrderStatus = OrderStatus.Draft
}

Prefer creating a new value:

val paidOrder = order.copy(status = OrderStatus.Paid)

This makes code easier to test, reason about, and safely use in concurrent contexts.

3. Use interfaces plus lambdas for Strategy pattern

The classic OOP Strategy pattern uses an interface:

interface DiscountStrategy {
    fun apply(total: Double): Double
}

class NoDiscount : DiscountStrategy {
    override fun apply(total: Double): Double = total
}

class PercentageDiscount(
    private val percent: Double
) : DiscountStrategy {
    override fun apply(total: Double): Double =
        total * (1 - percent)
}

In Kotlin, if the behavior is simple, you can replace the interface with a function type:

typealias DiscountStrategy = (Double) -> Double

val noDiscount: DiscountStrategy = { total -> total }

fun percentageDiscount(percent: Double): DiscountStrategy =
    { total -> total * (1 - percent) }

class CheckoutService(
    private val discountStrategy: DiscountStrategy
) {
    fun checkout(total: Double): Double =
        discountStrategy(total)
}

Usage:

val service = CheckoutService(
    discountStrategy = percentageDiscount(0.15)
)

val finalTotal = service.checkout(100.0)
println(finalTotal) // 85.0

This is a good example of mixing both styles:

• CheckoutService is object-oriented.
• DiscountStrategy is functional.
• The behavior is injected as a function.

Use an interface when the strategy has multiple methods or meaningful identity. Use a function type when it is just one operation.

4. Use sealed classes for type-safe state and results

Instead of nullable values, error codes, or large inheritance hierarchies, Kotlin often uses sealed classes.

sealed class PaymentResult {
    data class Success(val transactionId: String) : PaymentResult()
    data class Failure(val reason: String) : PaymentResult()
    data object Pending : PaymentResult()
}

Then handle all possible cases with when:

fun describe(result: PaymentResult): String =
    when (result) {
        is PaymentResult.Success ->
            "Payment completed: ${result.transactionId}"

        is PaymentResult.Failure ->
            "Payment failed: ${result.reason}"

        PaymentResult.Pending ->
            "Payment is pending"
    }

This combines:

• OOP-style polymorphic modeling
• FP-style expression-based branching
• Compile-time exhaustiveness checking

This is often cleaner than:

class PaymentResult(
    val success: Boolean,
    val errorMessage: String?,
    val transactionId: String?
)

because that structure can represent invalid states.

5. Replace some Template Method patterns with higher-order functions

Classic OOP Template Method might look like this:

abstract class ReportGenerator {
    fun generate(): String {
        val data = loadData()
        val formatted = format(data)
        return export(formatted)
    }

    protected abstract fun loadData(): List<String>
    protected abstract fun format(data: List<String>): String
    protected abstract fun export(content: String): String
}

In Kotlin, you can often use higher-order functions:

class ReportGenerator(
    private val loadData: () -> List<String>,
    private val format: (List<String>) -> String,
    private val export: (String) -> String
) {
    fun generate(): String {
        val data = loadData()
        val formatted = format(data)
        return export(formatted)
    }
}

Usage:

val generator = ReportGenerator(
    loadData = { listOf("A", "B", "C") },
    format = { data -> data.joinToString(separator = "\n") },
    export = { content -> "Report:\n$content" }
)

println(generator.generate())

This avoids subclassing when all you need is customizable behavior.

6. Use composition over inheritance

Kotlin works well when you compose small behaviors instead of building deep inheritance trees.

interface Logger {
    fun log(message: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) {
        println(message)
    }
}

class UserService(
    private val logger: Logger,
    private val validateUser: (User) -> Boolean
) {
    fun register(user: User) {
        if (!validateUser(user)) {
            logger.log("Invalid user: ${user.name}")
            return
        }

        logger.log("Registered user: ${user.name}")
    }
}

Here:

• Logger is an OOP abstraction.
• validateUser is a functional dependency.
• UserService composes both.

Usage:

val service = UserService(
    logger = ConsoleLogger(),
    validateUser = { user -> user.age >= 18 && user.isActive }
)

This is flexible without excessive inheritance.

7. Use extension functions to add behavior without modifying classes

Extension functions are useful when you want functional-style transformations around OOP models.

data class Product(
    val name: String,
    val price: Double,
    val category: String
)

fun Product.withTax(rate: Double): Product =
    copy(price = price * (1 + rate))

fun Product.isExpensive(): Boolean =
    price > 100.0

Usage:

val products = listOf(
    Product("Keyboard", 80.0, "Electronics"),
    Product("Monitor", 250.0, "Electronics")
)

val taxedExpensiveProducts =
    products
        .map { it.withTax(0.2) }
        .filter { it.isExpensive() }

This keeps your domain model clean while allowing expressive pipelines.

8. Use functional pipelines inside object-oriented services

You do not need to choose between “service classes” and functional pipelines. They combine naturally.

class InvoiceService {
    fun calculateTotal(items: List<InvoiceItem>): Double =
        items
            .filter { it.quantity > 0 }
            .map { it.price * it.quantity }
            .sum()
}

data class InvoiceItem(
    val name: String,
    val price: Double,
    val quantity: Int
)

The class defines the business capability. The method implementation uses functional collection operations.

9. Use command objects or lambdas for Command pattern

Classic OOP Command pattern:

interface Command {
    fun execute()
}

class PrintCommand(
    private val message: String
) : Command {
    override fun execute() {
        println(message)
    }
}

Kotlin functional version:

typealias Command = () -> Unit

val printCommand: Command = {
    println("Hello from command")
}

fun runCommand(command: Command) {
    command()
}

Usage:

runCommand {
    println("Executing inline command")
}

Use a class-based command when the command has state, metadata, undo behavior, or lifecycle. Use a lambda when it is just executable behavior.

10. Use Repository as OOP boundary, FP for business rules

A practical architecture pattern is:

• Repositories/gateways: OOP interfaces
• Use cases/services: classes
• Business rules: pure functions
• Data transformations: functional pipelines

interface UserRepository {
    fun findAll(): List<User>
    fun save(user: User)
}

class ActivateUsersUseCase(
    private val repository: UserRepository
) {
    fun execute() {
        repository
            .findAll()
            .filter { shouldActivate(it) }
            .map { it.copy(isActive = true) }
            .forEach { repository.save(it) }
    }

    private fun shouldActivate(user: User): Boolean =
        !user.isActive && user.age >= 18
}

This gives you:

• Testable boundaries
• Clear dependency injection
• Pure business logic where possible
• OOP structure where useful

11. Map design patterns to Kotlin idioms

Many GoF-style design patterns become simpler in Kotlin.

Example factory:

sealed class Notification {
    data class Email(val address: String) : Notification()
    data class Sms(val phoneNumber: String) : Notification()
}

fun createNotification(type: String, target: String): Notification =
    when (type) {
        "email" -> Notification.Email(target)
        "sms" -> Notification.Sms(target)
        else -> error("Unsupported notification type: $type")
    }

12. A practical mixed-style example

data class CartItem(
    val name: String,
    val price: Double,
    val quantity: Int
)

data class Cart(
    val items: List<CartItem>
)

typealias PricingRule = (CartItem) -> Double

class CartCalculator(
    private val pricingRule: PricingRule
) {
    fun total(cart: Cart): Double =
        cart.items.sumOf { item ->
            pricingRule(item) * item.quantity
        }
}

fun standardPricing(item: CartItem): Double =
    item.price

fun discountedPricing(discount: Double): PricingRule =
    { item -> item.price * (1 - discount) }

Usage:

val cart = Cart(
    listOf(
        CartItem("Book", 20.0, 2),
        CartItem("Pen", 2.0, 5)
    )
)

val calculator = CartCalculator(
    pricingRule = discountedPricing(0.10)
)

println(calculator.total(cart)) // 45.0

What this demonstrates:

• Cart and CartItem are OOP/value models.
• PricingRule is a functional strategy.
• CartCalculator is an object-oriented service.
• The total calculation uses functional collection operations.

General guidelines

Use OOP when you need:

• Domain concepts with identity
• Encapsulation
• Long-lived services
• Polymorphic boundaries
• Dependency injection
• External system boundaries like repositories, APIs, databases

Use functional programming when you need:

• Data transformations
• Stateless business rules
• Reusable policies
• Collection processing
• Validation
• Pipelines
• Behavior injection

A good Kotlin rule of thumb:

Model your domain with objects, model your behavior with functions, and keep state immutable unless mutation is clearly necessary.

That gives you Kotlin code that is expressive, testable, and maintainable.