Design Patterns in Kotlin Episode #2 | Kotlin Tutorial

แชร์
ฝัง
  • เผยแพร่เมื่อ 10 ธ.ค. 2024

ความคิดเห็น • 56

  • @Poisonedyouth79
    @Poisonedyouth79 2 ปีที่แล้ว +17

    Love this series ❤️

  • @bboydarknesz
    @bboydarknesz 2 ปีที่แล้ว +6

    thanks!
    this is cool series, with live code and more real implementation example

  • @jolly_joker
    @jolly_joker 2 ปีที่แล้ว +5

    Love it, hope to see more of this!

  • @scottloewke5199
    @scottloewke5199 ปีที่แล้ว

    Decorator is a good example of OCP: open for extension, closed for modification. Looking forward to reading this book. The Head First Design Patterns book has a good chapter that covers Decorator, although it's in Java.

  • @zhoon-kim
    @zhoon-kim 2 ปีที่แล้ว +5

    유익한 내용 감사합니다. 구현하면서 생각을 따라가게 되어서 정말 좋았네요. 마지막 내용을 보니 책으로 한 번 보고 다시 또 보면 더 좋을 것 같네요

  • @rodneymkay
    @rodneymkay 2 ปีที่แล้ว +13

    Not a big deal, but there's a small bit of audio missing at the 16 Minute mark :)

  • @hj2931
    @hj2931 2 ปีที่แล้ว +2

    nice video and nice book, thanks for sharing!

  • @sarpedonmontecarlo8397
    @sarpedonmontecarlo8397 2 ปีที่แล้ว

    Very interesting lesseon,
    Also enjoyed the educational atmosphere of you guys interacting with the code.
    Cheers!

  • @LA-fb9bf
    @LA-fb9bf 2 ปีที่แล้ว +1

    Very good! I like this deep dive!

  • @laujimmy9282
    @laujimmy9282 2 ปีที่แล้ว +1

    Great series, now I have a better idea on how we can use proxy and decorator

  • @gorttar
    @gorttar 2 ปีที่แล้ว +4

    Great video but there is more fundamental difference between proxy and decorator than described in video:
    Proxy is intended to provide a surrogate or placeholder for another object to control access to it
    Decorator is intended to add some functionality for another object without controlling access to it
    According to this, there is a difference in implementation: proxy controls creation of delegate (creates by itself or obtains from dependency injection container) while constructor of decorator takes delegate as a parameter.
    So both LoggingProcessor and CachingProcessor are actually deocrators rather than proxies.

    • @kyay10
      @kyay10 2 ปีที่แล้ว

      Isn't CacheProcessor "controlling access" to the underlying processor by not calling it sometimes?

    • @gorttar
      @gorttar 2 ปีที่แล้ว +1

      @@kyay10 no because you've access to underlying one from caller side: caller passes an instance of underlying processor to CacheProcessor constructor.
      Compare to Spring beans for example: all Spring injections you have in your bean are actually proxies and caller side never directly instantiate beans.
      In short: proxy tries to completely substitute and hide wrapped object while decorator is just another object with additional functionality.

  • @ramkumarkb
    @ramkumarkb 2 ปีที่แล้ว +4

    Great series 😍

  • @RatkaOdalovic-Radusinovic
    @RatkaOdalovic-Radusinovic ปีที่แล้ว

    @19:12 wanted to probably say the reverse. You converted proxy to decorator. Great video 🎉

  • @t54f
    @t54f 2 ปีที่แล้ว +3

    Great example 💯

  • @TheMassif
    @TheMassif 2 ปีที่แล้ว

    Great working example, love it ❤

  • @dibyaranjanmishra4272
    @dibyaranjanmishra4272 2 ปีที่แล้ว +4

    Great explanation

    • @Kotlin
      @Kotlin  2 ปีที่แล้ว

      Glad it was helpful!

  • @ArthurKhazbs
    @ArthurKhazbs 3 หลายเดือนก่อน

    Actually interesting to know: What parts of the book did you bookmark? I think sharing your tabs can be a fun thing to do and it would also help promote the book!

  • @markonovakovic3838
    @markonovakovic3838 2 ปีที่แล้ว

    great video, would love to see more episodes from this series and maybe some functional refactoring

  • @Никита-т5щ7ф
    @Никита-т5щ7ф 2 ปีที่แล้ว +3

    That's helpful, thanks!

  • @robchr
    @robchr 2 ปีที่แล้ว +5

    Now for the functional version! A processor is just a `(Request) -> Response` function and decorating is just map chaining functions.

    • @markonovakovic3838
      @markonovakovic3838 2 ปีที่แล้ว +1

      maybe fun interface Processor : (Request) -> Response would work better for most cases, you keep polymorphism and you get that functional look and feel

    • @donwald3436
      @donwald3436 2 ปีที่แล้ว

      Now explain why a monad is like a burrito.

    • @ArthurKhazbs
      @ArthurKhazbs 3 หลายเดือนก่อน

      @@markonovakovic3838 Oh yes, fun interface really is the fun part of Kotlin

  • @jakubgwozdz2780
    @jakubgwozdz2780 2 ปีที่แล้ว

    sometimes when people have problems figuring out what the decorator pattern is about, I tell them: "think about BufferedInputStream" and they are like "oh yes of course" :) (because indeed, a proxy and a decorator are so similar there's a little point to differentiate between them)

  • @hamzaproho6423
    @hamzaproho6423 2 ปีที่แล้ว

    Thank you so much buddy i digg whole youtube for this but you are the only one ❤️🔥

  • @chrismuga
    @chrismuga 2 ปีที่แล้ว

    This is simply. Awesome

  • @ehsan13671
    @ehsan13671 2 ปีที่แล้ว

    great examples. thanks!

  • @mayikx
    @mayikx 20 วันที่ผ่านมา

    Do you have a Playlist about it?

  • @camilocepedadanies
    @camilocepedadanies 2 ปีที่แล้ว

    very much your efforts to help us noobs out.

  • @amol_
    @amol_ 2 ปีที่แล้ว

    I implemented similar kind of pattern for Kafka consumer processing event, We had requirement where we need to check in inbox table for eventId before processing the event basically for duplicate check so what i did i created HOF and wrapped processEvent function in that. I hope Kotlin will have pattern matching like OCaml that this language will be rock :)

  • @xetra1155
    @xetra1155 2 ปีที่แล้ว

    So can we say that the Filter "Pattern" or at least how FilterChains are implemented is somewhat a mix of Proxy and Decorator? Because in a Filter there is a condition that decides if the next in line will be process/called?

  • @PedroBarbosaRoman
    @PedroBarbosaRoman 2 ปีที่แล้ว

    Would you say that Kotlin Flow and it's processing/transformation functions are a kind of a Wrapper pattern for a Type that is already implemented but for reactive programming?

  • @IsuruKusumal
    @IsuruKusumal 2 ปีที่แล้ว

    Decorator/Proxy often introduce a lost of unnecessary wrappings - we can achieve the same effect without introducing these wrappers/types by simply using extension functions

    • @FuNIpoxi
      @FuNIpoxi 2 ปีที่แล้ว +1

      Well not really I think, since the Decorator/Proxy allow to isolate the addon-behavior from the base type/interface. It means that this will allow you to compose concretions at your will later, depending on the usecase. The extension methods, on the other hand, will modify the behavior of the base type/interface for your whole project... so you can forget about composing behaviors together.
      Extension methods are cool, but I don't think they fit the need exposed in this video

    • @IsuruKusumal
      @IsuruKusumal 2 ปีที่แล้ว

      @@FuNIpoxi They defintely fit the need. I've written up the same solution with just extension methods. No need for a pattern, wrappers, types or nesting

    • @IsuruKusumal
      @IsuruKusumal 2 ปีที่แล้ว

      my gh tag is xxfast

    • @jakubgwozdz2780
      @jakubgwozdz2780 2 ปีที่แล้ว

      Extension functions can solve *some* off these needs too, but they are not design patterns. They are cool language flavors but under the hood they are just static utility functions. And it's a bit harder to properly compose them in a way presented in this wideo, especially sometimes desired non-associativity, when caching(logging(processor)) != logging(caching(processor))

    • @IsuruKusumal
      @IsuruKusumal 2 ปีที่แล้ว

      @@jakubgwozdz2780 in my implement above, I've composed this as a simple list of call chains
      Processor().log().cache() != Processor().cache().log()
      It is far more elegant to properly compose than to nest everything in object
      My point is that you don't need this design pattern

  • @_caioiglesias_
    @_caioiglesias_ 2 ปีที่แล้ว

    Packtpub redirects print purchases to Amazon ☹️

  • @scienceschool4998
    @scienceschool4998 2 ปีที่แล้ว

    How I wish I can write code they way you people do

  • @veygard
    @veygard 2 ปีที่แล้ว

    ty for video

  • @GulshanurRahman
    @GulshanurRahman 2 ปีที่แล้ว

    I think this should be called "middleware pattern"?

  • @muhammednuriozturk02
    @muhammednuriozturk02 2 ปีที่แล้ว

    works gj

  • @bahtiyaryudis6333
    @bahtiyaryudis6333 2 ปีที่แล้ว

    Ok

  • @donwald3436
    @donwald3436 2 ปีที่แล้ว

    It shouldn't be called Decorator or Wrapper, it should be called an around advice. Only half joking.

  • @TobiasKerst
    @TobiasKerst 2 ปีที่แล้ว +2

    way too many cuts in between sentences. Kills the video's flow and made me quit after the first few minutes.

  • @Quillraven
    @Quillraven 2 ปีที่แล้ว +4

    Out of interest: the caching can be a simple one liner,no?
    return cache.getOrPut(request) { processor.process(request) }

    • @kyay10
      @kyay10 2 ปีที่แล้ว +2

      Yep, or Seb could've used cache.get(request) ?: processor.process(request).also { cache.put(request, it) }

    • @jakubgwozdz2780
      @jakubgwozdz2780 2 ปีที่แล้ว +1

      yes I was surprised Sebastian didn't use it, but I guess it's better to focus on just one thing in the video and leave such flavours for other occasion.

    • @ArthurKhazbs
      @ArthurKhazbs 3 หลายเดือนก่อน

      There were quite a few lines of code that could be simplified, but that was out of scope for the video

  • @ThinkTablet
    @ThinkTablet 2 ปีที่แล้ว +1

    Thanks Folks, What if we change it so that caller could build it like this?
    newRequestProcessor()
    .decorateWithCache()
    .decorateWithLogging()
    is that confusing?

    • @jakubgwozdz2780
      @jakubgwozdz2780 2 ปีที่แล้ว +1

      drop the "new" and "decorate" and it's clear and readable :)

    • @donwald3436
      @donwald3436 2 ปีที่แล้ว +1

      I like that, like a builder. I guess each new decorator add an extension function to Processor? I'd prefer RequestProcessor().with(logger).with(cache) that delegates to the decorator constructors in a generic way... but no immediate ideas on how to make that happen.