Supercharge your Kotlin with Java Dynamic Proxies

Ғылым және технология

We left the last episode ( • Refactoring to the Rep... ) with the realisation that we can’t automagically delegate from an interface of suspend functions to an interface of non-suspend functions.
That seems like quite an arcane problem, but the solution is generally very useful. It turns that we can implement interfaces at runtime, running dynamic code to respond to method calls. This can save us from writing lots of boilerplate code, and is used in dependency injection, object relational mapping and mocking.
Unfortunately this technique is only applicable on the JVM, so if you are a Kotlin purist you may wish to look away now. For the rest of us, let’s have fun with dynamic proxies
In this episode
* 00:00:42 A tale of two interfaces
* 00:02:34 Implementing only one method in an interface with an object
* 00:03:31 Implementing an interface with a dynamic proxy
* 00:07:16 Dynamic proxies and Kotlin delegation are a match made in heaven
* 00:08:33 Generalise generalize generalise
* 00:10:31 IntelliJ bug moving a function to a new package?
* 00:11:40 IntelliJ bug moving file
* 00:12:05 Proxies for structural typing
* 00:20:59 Just one wafer-thin fly in the ointment
The code for this video is on a GitHub fork github.com/dmcg/ktor-document...
This video is in a playlist of Ktor episodes ( • Ktor ) and http4k ( • http4k )
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.

Пікірлер: 11

  • @xxsaifxx2450
    @xxsaifxx24508 күн бұрын

    what a lovely video it's really nice to get inspired from these types of videos... your videos really helping me to develop large projects and making them easier to maintain, thanks to the algorithm for recommending me this video got a single question here about the proxy approach so in testing why we would use proxy object if we were going to test all the functionality of the object is it a temporary approach for this case so we can test some of the functionality and leave the rest later but I would not do that for the sake of seeing a compile error and handling it the way I want

  • @RefactoringDuncan

    @RefactoringDuncan

    8 күн бұрын

    Thanks for your kind words. In testing we might use a proxy in place of a production object because it is easier to set up, or doesn’t launch missiles or somesuch - these are mock objects. In a couple of episodes’ time I think we will use a proxy that just slows down requests to the InMemoryCustomers in order to help test throughput. There are lots of places where we might want to augment existing functionality - see the decorator pattern.

  • @DavidWickes
    @DavidWickes21 күн бұрын

    Nice! Inspired an entire afternoon of hacking around with proxy objects. Just wondering why you looked up the method on `this.java.class` rather than directly invoking the method that was passed to the invocation handler? It _seems_ to work the same for the scrappy one I've tested... but maybe I'm missing something?

  • @RefactoringDuncan

    @RefactoringDuncan

    21 күн бұрын

    You can get away with the one passed to the invocation handler if your wrapped object implements the interface, but not otherwise?

  • @DavidWickes

    @DavidWickes

    21 күн бұрын

    @@RefactoringDuncan Right - that makes sense - and because we were faking the structural subtyping you needed to look up the method from one interface into the other interface. Makes sense now!

  • @RefactoringDuncan

    @RefactoringDuncan

    21 күн бұрын

    Next week's video shows that sometimes we have to look harder, down the back of the sofa, inside shoes, all sorts of places.

  • @i-am-the-slime
    @i-am-the-slime21 күн бұрын

    Java has caused so much pain, suffering, and damage to the entire industry. I'd rather be writing COBOL or punch cards.

  • @RefactoringDuncan

    @RefactoringDuncan

    21 күн бұрын

    Wow, that’s a bit extreme. Even if you would rather be writing something else, without Java there would be no JetBrains or Kotlin! Personally I find the language itself to be frustrating these days, but the JVM is an amazing technology and often the right tool for the job.

  • @jimmorrison2657

    @jimmorrison2657

    17 күн бұрын

    I also don't use Java anymore, but it's a bit daft to diss it so much. If it was that bad it wouldn't have been the biggest language in the world for fifteen years. Duncan, how's it going? We used to work together at Sony with Richard Care. Jim Morrison. Great channel by the way.

  • @RefactoringDuncan

    @RefactoringDuncan

    17 күн бұрын

    @jimmorrison2657 Wow blast from the past! I was, coincidentally, just chatting with Richard when I saw your message.

  • @jimmorrison2657

    @jimmorrison2657

    17 күн бұрын

    @@RefactoringDuncan Aha, ok nice one. That's good to hear. All the best!!

Келесі