Implementing Interfaces with Method Maps

Kent Beck has been writing recently on the idea of the adjacent possible and software design. The adjacent possible is the technological space that we can reach from where we are now in one hop - we don’t have to develop something intermediate before we can implement something useful.
In software, sometimes we add some code and find ourselves expanding the adjacent possible. I think that happens in this episode. I was just adding the ability to discard coroutine continuation parameters when we call one interface through another, but on refactoring that code to remove duplication, I think that I have uncovered a technique that will allow us implement the decorator pattern for interfaces by populating maps of functions.
In this episode
* 00:00:48 Mapping from suspend to non-suspend functions
* 00:02:29 Add a test
* 00:04:00 It fails because we are looking for a method with a continuation
* 00:04:26 Duplicate our current implementation and fix it to find the right method to call
* 00:07:56 Now fix the invocation to discard the continuation
* 00:09:39 Now what is trying to get out of this mess - it's first-class functions
* 00:14:06 Now remove some duplication
* 00:16:40 Now retrofit our new plan to our old code
* 00:19:37 We can compose creating our map if we step back a bit
* 00:21:51 That opens up new possibilities
* 00:23:21 Review
The code for this video is on a GitHub fork github.com/dmc...
Other videos on proxies can be found in a Reflection playlist • Reflection
This video is in a playlist of Ktor episodes ( • Ktor ) and http4k ( • http4k )
I get lots of questions about the test progress bar. It was written by the inimitable @dmitrykandalov. To use it install his Liveplugin (plugins.jetbra...) and then this gist gist.github.co...
If you like this video, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook (java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style.

[@erfansn869]

Thanks for this

[@PairingWithDuncan]

I hope you find it useful

[@Olekj]

Wouldn't there be a bug where if `invoke()` actually returned null, we'd incorrectly throw "No implementation for method $method"?

[@PairingWithDuncan]

Ooh good catch! Reflection is full of these little gotchas. Somewhere in the back of my mind when I was writing the code I was wondering about the implications of Map and how you tell the difference between not there and there but null. I should have listened to that voice.

[@PairingWithDuncan]

I think this fixes it
val invocationHandler =
this.getOrElse(method) {
error("No implementation for method $method")
} ?: error("Bad default logic for method $method")
invocationHandler.invoke(args ?: emptyArray())

[@Olekj]

@@PairingWithDuncan sweet! Really enjoying your videos ❤️

[@PairingWithDuncan]

Thank you, it’s nice to have somewhere to play and share the joy of it.