Dependency injection in functional programming (Kotlin)

tl;dr

• DI in FP can be achieved using partial function application or the Reader monad
• But DI may not make sense in FP
• An OO-FP-OO sandwich where the domain core is purely functional but the outer layers are OO and use a dependency injector could be a good approach for applications which have a lot of side-effects.
• All solutions have pros and cons, final choice depends on the task at hand and personal preference

When I started looking into functional programming, I kept wondering how DI works in this paradigm and was surprised to find that there are not many articles written about it, especially for beginners, so I decided I could try to help in filling that void by sharing what I've learnt. Therefore, the target of this article are the developers that have started looking into the functional paradigm and wonder how dependency injection works there, so I'll try to introduce every topic without assuming much prior knowledge. The language I use is Kotlin, though the principles are universal. The article should preferrably be read from top to bottom, as the explanation of the concepts follow a logical order. Let's start!

Why functional programming?

Like many developers, the past couple of years I started gaining a lot of interest in functional programming due to all the problems I've seen in practice with mutable state. As an Android developer for the past 5 years, I've experimented these problems with the wide adoption of the MVP architecture. At the time it was all the rage as it allowed us to move away from untestable God-Activities/Fragments and have the presentation logic delegated to testable Presenters. As new features were implemented and requirements changed, our presenters would start to look like the old huge activities/fragments, and making any change would become increasingly dangerous, as presenters modify the view in imperative style (e.g. view.showLoading()) and multiple view-changing functions were in place. We'd split the presenters further but still, the complexity of not knowing if a change would affect something else was there. There had to be a better way!

One day I was still in the office (XING Barcelona) while a meetup was held in which the speaker was introducing Redux to the audience. I'm glad I decided to stay as it ultimately inspired me and got me to learn about functional programming. I started digging and discovered that Redux was partly inspired by Elm and then I started checking Elm.

Elm is an awesome pure functional language that tries very hard to be beginner friendly and while I think it does a great job, the paradigm shift is still enourmous. It's not so much the syntax itself, but the mindset change from an imperative to a functional one (to the Android folks, do you remember when you started with RxJava?). After some practice I began feeling comfortable with Elm, but I still remembered a conversation with a colleague in which he was trying to explain "monads" to me (Elm doesn't have them). No matter how many articles I'd read (including this one with pictures) I still wouldn't get it. The thing is that most, if not all articles focus on the "what", but not "why" we need monads. That's when I decided to go all-in and teach myself Haskell.

After reading LYAH and chunks of Haskell Programming (amazing book btw) I decided to do some practice by building an ArnoldC compiler for fun. The experience was very rewarding, even if I end up never using Haskell professionally. It's forever changed the way I look at code but while I do know what a monad is now, I'm also convinced that type classes (functors, applicatives, monads...) are not essential to functional programming, as Elm or Elixir show. Abstraction is a tool, not a goal! I'm aware this is opinionated and others may have a different opinion, which is fine. I think that type classes are especially useful for library writers when they strive to provide generic solutions but end-user application features rarely need such level of abstractions.

Joe Armstrong said "state is the root of all evil" and I subscribe to it. I've concluded that with these 2 principles you can get very far:

• Immutability
• Referential transparency (for a given input, you get the same output always with no side-effects)

As long as your programming language has first-class/top-level functions, just applying those 2 principles can get you a long way.

Pure functions excel at transforming data. For any given input, it'll return the same output, without side effects. This makes functional programming suitable for applications that resemble pipelines in which the input data is transformed through various stages. Examples of such applications are parsers, compilers, data analysis, etc.

But what about UI or CRUD applications? These sort of applications are basically full of side-effects. How can we fit a functional programming paradigm here? Doesn't this go against the 2 principles mentioned before?

So in the quest for trying to use functional programming to solve the same problems I've been running into the past few years, I've tried to force myself to strictly apply functional programming and see how it goes.

I built a sample server application in Kotlin to test the waters, having the 2 principles above in mind. It's a very simple Spring Boot application that exposes an endpoint that returns some data. Internally, the app will call another endpoint and process the results before returning a response. Fairly standard.

To be functional I followed these guidelines:

• Use only functions, avoiding classes except for the glue initialization code. Having no classes and just functions encourages you to think in terms of data transformation and avoid state.
• Use val and immutable data structures (Map, List...).
• Avoid side effects.

I followed Clean Architecture and separated my code in 3 logical layers: presentation, domain and data. When the server receives a request, the logic will flow like

request handler -> interactor -> external services

All good. But then I ran into a problem... How do I achieve DI? My interactors (domain) are no longer classes so I can't inject them the repositories that they should be calling.

If you look up "functional programming dependency injection" in Google, you'll find that there's (perhaps) surprisingly very little literature written on the topic. I may have an idea why that's the case but bear with me and keep reading! I'll be covering two of the most typical approaches:

• Partial function application
• Reader monad

There are other styles that can help you achieve similar goals, such as the tagless-final pattern or free monads, but I'm not going to cover them in this article.

Dependency injection goals

Before we look at functional programming's solutions to DI, let's take a step back and reflect on the problem that we're trying to solve. Without going into too much detail, we could summarize the DI goals as:

• Inversion of Control and loose coupling. Implementations don't choose their dependencies. This allows the caller to supply the specific implementations of these dependencies, allowing the behavior of the code to be configured externally. Typically, this is done by making classes depend on interfaces, the implementations of which are passed-in via constructor.
• Unit testing. This derives from the previous goal, as it allows us to inject mock implementations into the class under test.

Let's take a look at how we might achieve these goals with functional programming.

Partial function application

Partial function application is a very cool concept in functional programming that consists in passing some of the parameters to a function and getting a function that accepts the rest of the parameters in return. This concept derives from currying, which is a technique by which any function of N arguments can be translated into a sequence of N functions of 1 argument. For example:

fun sum(a: Int, b: Int): Int = a + b
sum(1, 2) // returns 3

// can be converted into a function that accepts 1 argument (a)
// and returns another function that accepts 1 argument (b)
fun sum(a: Int): (Int) -> Int {  
    return { b -> a + b }  
}

val sum1 = sum(1)
sum1(2) // returns 3

How can this help us? Imagine that we want to be able to inject different loggers into a function. We might want one that simply prints its output to the console or we might want another one that stores the log in a file. We can partially apply the function with the logger and the resulting function won't need the logger parameter anymore.

typealias ItemFetcherFn = () -> List<Item>

fun fetchItemsLogged(log: (String) -> Unit): ItemFetcherFn  {
    return {
        log("Fetching items")
        // fetch and return items...
    }
}

// let's use partial application to "inject" some logger
val consoleLogger: (String) -> Unit = { str -> println(str) }
val fetchItems: ItemFetcherFn  = fetchItemsLogged(consoleLogger)

// we can now use fetchItems anywhere, without knowing it has a logger
fun onStart(fetchItems: ItemFetcherFn ) { ... }

onStart(fetchItems)

This technique was the one I used in the master branch of my sample project. As I mentioned before, I separated the code in 3 logical layers (clean architecture style): presentation (or controllers), domain and data. If you remember the dependency rule, the inner layer cannot access the outer layer. Our inner layer is the domain layer, so it shouldn't have references to the presentation and the data layer (note that a Repository is considered an interface to the data layer, and the domain can reference interfaces). With this in mind, let's analyze our example starting with the data layer's Services.kt:

fun getUserTodos(
    baseUrl: String,
    userId: Int
): Mono<List<Todo>> {
    return WebClient.create(baseUrl).get()
        .uri { uriBuilder ->
            uriBuilder.path("/users/$userId/todos")
                .build()
        }
        .retrieve()
        .bodyToMono(object : ParameterizedTypeReference<List<DataTodo>>() {})
        .map { dataTodos -> dataTodos.map { it.toDomain() } }
}

From the domain layer's perspective, this function has a baseUrl, which is clearly a data layer detail. From the domain we shouldn't be concerned about where we get the data from. If we were using OO, this function would be encapsulated in a Repository object and baseUrl could be injected via constructor, so the function signature that the domain layer would end up using is fun getUserTodos(userId: Int). How can we achieve this in functional programming style? Using partial function application! We could partially apply baseUrl. Let's see how this looks in practice for Interactors.kt:

typealias TodoFetcherFn = (userId: Int) -> Mono<List<Todo>>

fun getCompletedTodos(fetchTodos: TodoFetcherFn, userId: Int): Mono<List<Todo>> {
    return fetchTodos(userId).map { todos -> todos.filter { it.isCompleted } }
}

Our domain function depends on a function of type TodoFetcherFn that takes a userId and returns a Mono<List<Todo>>. We're not depending on any specific implementation and as such the function is unit testable, so we achieved our DI goals. As long as we pass in a function that complies with this signature, we're good to go!

Let's see how this function is partially applied and "injected". This is Todos.kt from the controller layer:

fun getTodos(request: ServerRequest, fetchTodos: TodoFetcherFn): Mono<ServerResponse> {
    val userId = request.pathVariable("id").toIntOrNull()

    return if (userId != null) {
        val todosResponseMono =
            getCompletedTodos(fetchTodos, userId)
                .map { it.toResponse(userId) }
                .onErrorResume { e -> internalServerError(e) }

        ServerResponse.ok().contentType(MediaType.APPLICATION_JSON)
            .body(todosResponseMono, GetTodosResponse::class.java)
    } else {
        ServerResponse.badRequest().syncBody("id is not an integer")
    }
}

And finally this is the injection root (SampleApplication.kt):

@Configuration
class Router @Autowired constructor(
    @Qualifier(TODOS_BASE_URL) private val todosBaseUrl: String
) {

    @Bean
    fun routes(): RouterFunction<ServerResponse> = router {
        accept(MediaType.APPLICATION_JSON).nest {
            GET("/user/{id}/completedtodos") {
                getTodos(it, getTodosFetcherFn())
            }
        }
    }

    private fun getTodosFetcherFn(): TodoFetcherFn {
        return ::getUserTodos.partially1(todosBaseUrl)
    }
}

The sample is using Arrow to partially apply the first argument of getUserTodos (baseUrl). This function is then passed to the route handler, which then calls the interactor function with it.

Using partial function application we've successfully achieved FP's version of dependency injection. However, you might have some questions.

How do you test the route handler (getTodos) in isolation?

Fair question. If you want to test getTodos, you'd inevitably test getCompletedTodos as well as it makes a direct call to it. My advice is to not test it in isolation, test the whole feature. Just use a mock web server and test the whole feature end-to-end. There are many benefits to this approach.

Still, this is my opinion and you may not agree. If you really want to test it separately, you could make getTodos depend on a function that you'd pass in instead of having it call getCompletedTodos directly. I accidentally did that in a previous commit, so you could check how it'd work. Note that that implementation is wrong, the fetchTodos function that's passed in should have a signature separate from TodoFetcherFn from the domain layer, even if they look the same, so that we keep the functions independent.

If you have 5 dependencies, do you pass 5 arguments down?

My example is unrealistic as any real application will likely have more dependencies than that. For simplicity I'm just passing the function that I know I'll use, but you could construct a composition root in which you partially apply the functions that will have to be called as we go through the layers. Then you only have to pass the functions that will have to be called in the immediately next layer. Check how this works here. Another approach would be to pass a single argument with all the dependencies, which is what you'd do with the Reader monad.

The dependencies appear as arguments in the function signature of all functions in the call chain

Indeed. Whether that's cool or not is subjective, but there's a technique in functional programming that allows us to pass an argument implicitly so that it disappears from the argument list of your functions. Meet the Reader monad in the next section!

Code navigation is more difficult as cmd + click doesn't work on partial function signatures

Yes. If you think about it, the key idea of using partial application for DI is loose coupling, so you're not supposed to know which function was originally partially applied. If we organize the code in a way that we don't have deeply nested calls of partially applied functions, it should be simple to find the root.

I hope I managed to explain the technique in an understandable way, but if it's not enough or if you simply would like to see another take, there's an awesome article by Scott Wlaschin explaining it with a more complex example.

The Reader monad

We've found that passing the same argument down a chain of functions can be (subjectively) annoying. I mentioned that the Reader monad can allow us to pass that argument implicitly... how's that possible? We could put it in some global value and access it directly where needed. We no longer need to pass it to any function! But then this is just hardcoding and beats completely the purpose of dependency injection, in case we lost sight of our initial goals.

Alright, so what is the Reader monad about? To properly understand it we'd first need to understand what's a monad and why do we need it. Before that, you'd need to be introduced to functors and applicatives. It personally took me a lot of time to figure it out, even after reading many explanations and seeing them represented as pictures. I actually never got it until I actually used them in practice, so I'm not going to attempt to explain all the concepts here.

Instead, let's see if we can build an intuition about it. We can start by stating our goals clearly:

• Pass an argument to all functions in a call chain
• Do so without explicitly having it in the parameters list of these functions

If we call a function that returns a value, we get that value straight away. However, if we want to defer this computation, we can wrap that value in a function and return it. Then we won't get the value until we call this returned function.

fun giveMe5(): Int = 5

fun deferGiveMe5(): () -> Int = { 5 }

giveMe5() // returns 5
deferGiveMe5()() // returns 5

What if we connected a bunch of functions that return functions that take the same input? The result would be a function chain that wouldn't be evaluated until we actually call it and then we can pass some input down the chain.

fun delegateNum(): (Int) -> Unit {
    return { num -> furtherDelegateNum()(num) }
}

fun furtherDelegateNum(): (Int) -> Unit {
    return { num -> printNum()(num) }
}

fun printNum(): (Int) -> Unit {
    return { num -> println(num) }
}

val chain = delegateNum()
chain(5) // prints 5

5 in this case would be the "thing" that we want to inject down the chain. It could be the dependency that we need to make available to all the functions in it and it's implicit! So we achieved the goals we set before.

Now, notice how delegateNum(), furtherDelegateNum() and printNum() have the same structure. It turns out we can abstract this and this is loosely speaking what the Reader monad is about! Create a lazy (as in deferred evaluation) chain of functions that can read a common value, and then run this chain passing the value that we want.

Hopefully at this point I managed to give you an idea of the Reader monad, so let's see it with a real example. I didn't create a version of our example but we can use one from Jorge Castillo that shares a similar architecture to the one I used previously, although his example is an Android app. In his example he's fetching a list of superheroes from some endpoint. Let's check the data source:

// MarvelNetworkDataSource.kt

/*
 * This is the network data source. Calls are made using Karumi's MarvelApiClient.
 * @see "https://github.com/Karumi/MarvelApiClientAndroid"
 *
 * Both requests return a new Reader enclosing an action to resolve when you provide them with the
 * required execution context.
 */
fun fetchAllHeroes(): Reader<GetHeroesContext, IO<List<CharacterDto>>> =
    ReaderApi.ask<GetHeroesContext>().map({ ctx ->
      IO.monadDefer().binding {
        val result = runInAsyncContext(
            f = { queryForHeroes(ctx) },
            onError = { IO.raiseError<List<CharacterDto>>(it) },
            onSuccess = { IO.just(it) },
            AC = ctx.threading
        ).bind()
        result.bind()
      }.fix()
    })

The value that's passed down through his function chain is ctx, which is of type GetHeroesContext, which is a data class with all the dependencies that this chain needs (see SuperHeroesContext.kt).

This function is called from getHeroes(HeroesRepository), which is called from HeroesUseCases.kt:

fun getHeroesUseCase() = getHeroes(NetworkOnly).map { io -> io.map { discardNonValidHeroes(it) } }

which is then called from getSuperHeroes(SuperHeroesPresentation.kt), which is finally called from SuperHeroListActivity.kt:

override fun onResume() {
    super.onResume()
    getSuperHeroes().run(heroesContext)
}

Notice how heroesContext is passed down the function chain through the run function and how there's no trace of it in the parameters of the functions in the chain.

So this is how you do DI with the Reader monad! If you feel the need for a more technical explanation, check this post from the author himself.

Now, you might again have some questions...

How do you decide between the Reader monad and partial application?

This is a common question. The main reason people usually use the Reader monad is to avoid passing the same argument over and over again. Still, this may be subjective.

I said in the introduction that in my opinion these sort of abstractions (typeclasses) are not strictly necessary and we have an alternative to it, but whether you prefer it or not is subjective to a certain point. I personally don't currently feel I need them with the approach that I'll suggest later (I will tell you about it below, keep reading!).

Aren't we coupling all the functions in the Reader chain to the value that we're passing?

I think so... any function in the chain will be able to access the value that we're passing. In the example above, any of these functions has access to GetHeroesContext. I'll go in more detail in the next section.

A critical view

We've seen 2 ways of achieving DI in functional programming, but while we did achieve the goals that we set in the beginning, is this way of doing things better than having a dependency injection framework in OO style?

Regarding partial function application, a user named Onur left a thought-provoking comment in the Scott Wlaschin's article that I already mentioned before:

This is a much needed article unfortunately it misses the point. Normally, objects are not composable. Dependency Injection is a cure for that. Just like functional programming uses functions to build larger programs, dependency injection is used to build larger object programs. In your examples, dependencies are only represented in 1 level but there can be far more deep hierarchies. Secondly, dependency injection registration is a way to achieve inversion of control, such that the components don't create themselves, but registrations are like a recipe that describes the dependencies and hierarchy and is external to the application. Thirdly, dependency injection also incorporates to the life times of the components. Finally, all of these imply impurity.

This is indeed very true. The composition root in our case is arguably not external to our application. We've got it in our router function. We could tuck it away by putting it into some other file, but we still need to manually define the partial function applications that we want to pass to our specific entry function, whereas with a DI framework we'd simply define the provider functions somewhere and then simply declare what we want to use in the constructors.

Lifetime is another thing... lifetime as such doesn't make sense in a pure context but things such as a database connection have a lifetime. So DI implies impurity, does it make sense to try to do it in the functional world?

Let's come back to the last concern of the previous section. Isn't using the Reader monad in our example implying that we're coupling all our functions in the chain to the dependency context that we're passing? Let's check SuperHeroesContext:

sealed class SuperHeroesContext(ctx: Context) {

  val heroDetailsPage = HeroDetailsPage()
  val apiClient
    get() = CharacterApiClient(MarvelApiConfig.Builder(
        BuildConfig.MARVEL_PUBLIC_KEY,
        BuildConfig.MARVEL_PRIVATE_KEY).debug().build())
  val threading = IO.async()

  data class GetHeroesContext(val ctx: Context, val view: SuperHeroesListView) : SuperHeroesContext(ctx)
  data class GetHeroDetailsContext(val ctx: Context, val view: SuperHeroDetailView) : SuperHeroesContext(ctx)
}

This context has 5 dependencies. Let's see MarvelNetworkDataSource.kt again:

fun fetchAllHeroes(): Reader<GetHeroesContext, IO<List<CharacterDto>>> =
    ReaderApi.ask<GetHeroesContext>().map({ ctx ->
      IO.monadDefer().binding {
        val result = runInAsyncContext(
            f = { queryForHeroes(ctx) },
            onError = { IO.raiseError<List<CharacterDto>>(it) },
            onSuccess = { IO.just(it) },
            AC = ctx.threading
        ).bind()
        result.bind()
      }.fix()
    })

We can see that we're accessing ctx.threading and ctx is passed to queryForHeroes, which internally accesses apiClient. But what's impeding us to also access ctx.view or ctx.heroesDetailPage? Should those be available to the data layer? I think we're violating the dependency rule. Besides that, generally speaking it's a good idea to strive for "making impossible states impossible" (see talks by Richard Feldman and Patrick Stapfer, or this article). If we can't access ctx.view, there's no way we can do anything about it!

We've showed that we can achieve DI with partial function application or the Reader monad, but the question is, should we?

OO-FP-OO, a hybrid approach

Let's remind ourselves of the things we like most about functional programming:

• Immutability. Once a data value is created, we can never modify it.
• Referential transparency. Given a function and an input value, you receive the same output, without side effects, every single time.

These properties make it easier to reason about programs, as you can be sure about the behavior being consistent. If the language is statically typed, equational reasoning becomes possible. This is going to make us have less bugs and less cognitive load, as your thought context should just be the function you have in front.

Typical Android applications or backend CRUD services are full of side effects. You need to access the network or a database to retrieve some data, and then you need to modify the UI to display this data or return some Json response. On top of that, like most languages Kotlin does not have a way to enforce referential transparency, so you can use any typeclass that Arrow provides but there's nothing preventing you from doing side effectful code that can be something as apparently harmless as a println or you could just call Thread.sleep(...) and stop the world. In practice, this means we need to follow some guidelines and make sure everybody in our team is aware of them.

If we need to access the network or the database and we can't enforce purity anyway, why aren't we even more pragmatic and simply do these in OO style? Our domain logic is what can be isolated from external factors such as UI or the data layer, so we could write it in FP style. If you view our business logic as a deterministic black box, you can just pass some data in (loaded from a DB), get some data out and render it to the UI.

data layer input -> domain logic -> output UI

As you can see, the domain logic is in the middle. If the rest is OO, we get a OO-FP-OO sandwich (I was inspired by Dax Fohl for the concept, although he's suggesting an FP-OO-FP approach).

Going back to what this article is about and the open question left at the end of the previous section, we could continue to leverage our DI framework and just keep our business logic core functional. Note that this doesn't mean that we should start having mutable state everywhere in the OO part. My approach would be "prefer FP over OO", which means to generally have an FP mindset but be pragmatic and use OO sparsely when it's much more convenient and it's not dangerous.

I tried this approach in another branch of the example. The domain logic stays exactly the same as in the partial application case:

// Interactors.kt
fun getCompletedTodos(fetchTodos: TodoFetcherFn, userId: Int): Mono<List<Todo>> {
    return fetchTodos(userId).map { todos -> todos.filter { it.isCompleted } }
}

However, now Repositories.kt takes advantage of Spring Boot's dependency injection system to inject the base url:

@Component
class UserTodosRepository @Autowired constructor(
    @Qualifier(ExternalServices.TODOS_BASE_URL) private val baseUrl: String
) {
    fun getUserTodos(userId: Int): Mono<List<Todo>> {
        return WebClient.create(baseUrl).get()
            .uri { uriBuilder ->
                uriBuilder.path("/users/$userId/todos")
                    .build()
            }
            .retrieve()
            .bodyToMono(object : ParameterizedTypeReference<List<DataTodo>>() {})
            .map { dataTodos -> dataTodos.map { it.toDomain() } }
    }
}

And it's injected into the route handler, who only passes the UserTodosRepository::getUserTodos function to the domain function.

@Component
class TodosHandler @Autowired constructor(
    private val repository: UserTodosRepository
) {
    fun getTodos(request: ServerRequest): Mono<ServerResponse> {
        val userId = request.pathVariable("id").toIntOrNull()

        return if (userId != null) {
            val todosResponseMono =
                getCompletedTodos(repository::getUserTodos, userId)
                    .map { it.toResponse(userId) }
                    .onErrorResume { e -> internalServerError(e) }

            ServerResponse.ok().contentType(MediaType.APPLICATION_JSON)
                .body(todosResponseMono, GetTodosResponse::class.java)
        } else {
            ServerResponse.badRequest().syncBody("id is not an integer")
        }
    }
}

As we're using the DI framework, we no longer need to have the partial application boilerplate in the outer layers. Also, our data layer could just request the dependencies it requires, instead of having a context injected with the dependencies required across all the layers involved in a feature, like in the Reader monad case.

A purist could say that the functional core shouldn't know anything about a getUserTodos function, but should be fed the user todos directly. Our domain function would simply filter by isCompleted and do nothing else. Essentially, side-effects are pushed to the outer layers. This style is similar to the "Ports and Adapters" architecture and is well described by Mark Seemann here (warning: F# and Haskell ahead!). Fair enough, though you could also argue that we'd do that at the expense of having the business logic pushed to the outer layers just so we can have a pure functional core.

In any case, you can see that we can successfully mix OO and FP and use them for what they're best at. DI frameworks are convenient and as long as we keep the side-effects well encapsulated in our OO parts and the pure data processing parts in FP style, we can have the best of both worlds!

Conclusions

We've seen that using partial function application or the Reader monad we can have similar results to OO-style dependency injection. However, they may not be the best approaches as they seem more like an almost direct translation of the OO pattern into the functional world.

OO and FP are not mutually exclusive, we can use both of them where they work best. An OO-FP-OO sandwich in which the business core is functional and outer layers use OO may be a pragmatic approach forward.

In any case, each approach has its pros and cons and which one you choose will depend on your task at hand and your own preferences.

Partial function application

+ Functional approach (no classes)
+ Explicit, no magic
+ Simple to implement
- Verbose (in Kotlin + Arrow)
- Lots of manual setup in the composition root.

Reader monad

+ Functional approach (no classes)
+ Relatively explicit
- Single parameter passed down through all layers (if used as in the example we used)
- Manual setup in the composition root
- Different layer dependencies may be accessible to all functions in the chain

OO-FP-OO, hybrid approach

+ Concise code
+ Easy to specify dependencies
+ DI framework takes care of the composition boilerplate
- DI is magical, especially when you're not familiar with the framework
- Uses classes
- Classes may encourage stateful code
- Developers need to be strict in trying to keep the functions pure and making sure that classes are only used for DI and not to hold state

I personally find the hybrid approach a good pragmatic one in Kotlin, but be mindful about the cons, especially the last one.

This was a long post! I hope you enjoyed the read and see you next time!