Adapter Design Pattern Explained with Spring Boot | Real-Time Example |

Поділитися
Вставка

КОМЕНТАРІ • 60

  • @DukeJava-x7z
    @DukeJava-x7z 3 місяці тому +5

    I really find your teaching style efficient and useful. You explain the problem first, then show the solution, then you show a real-world use case. Really appreciate it ❤
    Please continue with this design patterns real-world examples ❤❤❤

    • @Javatechie
      @Javatechie  3 місяці тому

      Thank you buddy for appreciating it 😀. Keep learning

  • @sivakokkiligadda365
    @sivakokkiligadda365 Місяць тому +1

    Thank you so much sir, I tried multiple websites for this design pattern and multiple vides. This is amazing explanation. Thank you so much again.

  • @gopishettymahindra2713
    @gopishettymahindra2713 3 місяці тому +1

    Thank you Basant sir. I really like your way of teaching.

  • @universal4334
    @universal4334 3 місяці тому +8

    21:00 Why do you want to do manual entries to map. Anyway, spring injects the beans right, if you have specific names to all components. I dont see you're making two incompatable services to make compatable using adapter anywhere here. This is more of a kinda stratergy and factory, where you're deciding implementation runtime(stratergy) and getting bean based on decision(factory)

    • @Phoenix-od2bp
      @Phoenix-od2bp 3 місяці тому +4

      Agree, this is not adapter, but more like strategy pattern.
      Adapter is to make the interface compatible, implies the payment service implementation of “make payment” changes the adapter should hide it from the client. The client should still be able to call this method, but the adapter makes appropriate calls to facilitate the payment of the target class.

    • @Javatechie
      @Javatechie  3 місяці тому +2

      That's what I have done right. Only the mistake I haven't cover incompatible stuff by creating different method with name That's why it's confusing buddy. I will remake this with more meaningful usecase

    • @Phoenix-od2bp
      @Phoenix-od2bp 3 місяці тому +1

      @@Javatechie Design patterns are tricky, some of them look similar, the definition and intention should guide us.
      In your example Basant, instead of having different payment services, a better way of showing this pattern would have been, if say “Paypal” had a “process payment” method with one implementation say taking amount in integer or so and later it changed to a different one say taking a float or BigDecimal value, the client will call the adapter and the adapter would make the call to paypal with appropriate arguments and that way the client is hidden from the changes.
      You are almost there with your example, but it does not show the following point. Correct me if I am missing something.
      The Adapter Design Pattern solves this problem by defining a separate adapter class that converts the incompatible interface of a class (called the “adaptee”) into another interface (called the “target”) that clients require.
      Still enjoyed your presentation and found it useful. Thank you for taking the time to share your knowledge.Appreciate it!

    • @Javatechie
      @Javatechie  3 місяці тому +2

      I apologise for confusion . I relaise after read many comments . I could make it better by focusing more on the incompatible usecase. Thanks for detailed information @Phoenix I will remake this with clear context

  • @gopisambasivarao5282
    @gopisambasivarao5282 3 місяці тому +1

    Appreciate Basant your efforts!God bless you!👍🙏😊

  • @Bruce_mani
    @Bruce_mani 3 місяці тому +1

    Thank you, Basant, for uploading the video.

  • @jagadeeshp4708
    @jagadeeshp4708 3 місяці тому +1

    Thanks you Basant for sharing this concept it will help many people interview point

  • @sabariPInterview
    @sabariPInterview 3 місяці тому +1

    21:00.. we can have one more abstract method returning gateway type(string).. so instead of storying class name in map.. we can store gateway type directly

    • @Javatechie
      @Javatechie  3 місяці тому +1

      Yes that's a good suggestion 👍

  • @vincentmax4571
    @vincentmax4571 3 місяці тому +1

    Awesome!!!!

  • @pradipgarala
    @pradipgarala 3 місяці тому +1

    No need write a custom logic to populate map in constructor @ 23:00.
    Spring will autowire all the beans based on interface
    @Autowired
    private Map paymentProcessorMap;

    • @Javatechie
      @Javatechie  3 місяці тому +1

      Ohh is it . Great let me try this. Thank you for the update buddy 😀

    • @universal4334
      @universal4334 3 місяці тому +1

      @@Javatechie yeah exactly this i what I told in my comment, instead of manually mapping beans if we have name to to the component like @component ("paypalAdapter") so on...then when you do Map and do constructor injection spring will automatically injects all the components that implemented PaymentProcessor

    • @Javatechie
      @Javatechie  3 місяці тому +1

      Thank you buddy. Interesting concept i was not aware about it.

  • @javafasttrack3439
    @javafasttrack3439 3 місяці тому

    I recently did same changes - where I created interface had three implementation class and my spring container has three beans. i had else if statement to assign it processor then i call unified method. Thanks for the constructor which is holding all the processors.

  • @thereisnonelse
    @thereisnonelse 3 місяці тому +1

    Amazing ...

  • @sambasivarao4958
    @sambasivarao4958 3 місяці тому +1

    Hi Bro, interew questions, can you please share more details about transaction management

  • @girishrp9339
    @girishrp9339 3 місяці тому +2

    Easy to understand this concept. Can you make video of Kafka connect to Snowflake database.

    • @Javatechie
      @Javatechie  3 місяці тому +1

      Kafka connect i tried but struggling to resolve the issue buddy need some more time to publish a content on it .

    • @girishrp9339
      @girishrp9339 3 місяці тому +1

      @@Javatechie thanks for the update!!

  • @fsdinterviewguide
    @fsdinterviewguide 3 місяці тому +1

    Thank you.

  • @parmodprajapati
    @parmodprajapati 3 місяці тому +1

    Hi,
    The concept is clear on the adapter.
    I tried it using qualifiers but changes required in qualifier annotations,
    Again and again I am required to change parameters
    Could you make one video on qualifiers where they do not require to change as in this video based on parameter gpay object created

    • @Javatechie
      @Javatechie  3 місяці тому

      @@parmodprajapati sure buddy will do that

    • @mr-black_rock321
      @mr-black_rock321 Місяць тому

      This is not adapter pattern

  • @krishnapriya-b7s
    @krishnapriya-b7s 3 місяці тому +2

    Whats the difference between adapter and factory design pattern...i see both needs interface implementation.

    • @Javatechie
      @Javatechie  3 місяці тому

      Interface is the key bones of Oops buddy 😬

    • @sharathkumar2018
      @sharathkumar2018 3 місяці тому

      ​@@JavatechieI don't see much difference between adapter and factory

  • @maheshr7827
    @maheshr7827 3 місяці тому

    Entity Graphs ...can you make video with real-world examples

  • @aadiraj6126
    @aadiraj6126 3 місяці тому +2

    Basant Bhai, We need "Port & Adaptor" design pattern, which is also known as Hexagonal Architecture Pattern..

    • @Javatechie
      @Javatechie  3 місяці тому

      Surely I will plan for it

    • @universal4334
      @universal4334 3 місяці тому +1

      ​@@Javatechieexactly please plan this. This helps alot in real time. Hexagonal, onion etc..

    • @Phoenix-od2bp
      @Phoenix-od2bp 3 місяці тому +1

      You beat me to it, was about to request Basant for the same. I have implemented it a year back but need a refresher and Basant explains it the best.

    • @vivekguptacs
      @vivekguptacs 3 місяці тому +1

      Yes.. Plan for this basant

  • @Aamirkhan-oc4xd
    @Aamirkhan-oc4xd 3 місяці тому +1

    Basant Bhai, we need videos on gRPC

    • @Javatechie
      @Javatechie  3 місяці тому +1

      Surely I will plan . Noted ✅️

    • @universal4334
      @universal4334 3 місяці тому

      Awesome! Been waiting for this as well. Everywhere it is Rest not grpc. It will be great if you take on grpc basant

  • @CenturionDobrius
    @CenturionDobrius 3 місяці тому +4

    this is not adapter pattern, it's more strategy/factory pattern...

    • @Javatechie
      @Javatechie  3 місяці тому

      Can I get some more insights on adapter design pattern buddy

    • @universal4334
      @universal4334 3 місяці тому

      💯

    • @CenturionDobrius
      @CenturionDobrius 3 місяці тому +1

      ​@@Javatechie really no need to delete my reply I was sincere with my answer.
      And I really appreciate your work any way

    • @Javatechie
      @Javatechie  3 місяці тому +1

      @@CenturionDobrius i never delete anyone's comment buddy irrespective of good or bad . Because all the way i am learning so Let me check with my team and sorry for it . Please add it again . Thank you for appreciating my work

    • @CenturionDobrius
      @CenturionDobrius 3 місяці тому +1

      ​@@Javatechiethanks, and keep with high quality work !

  • @itsnarahari
    @itsnarahari 2 місяці тому

  • @youkaba97
    @youkaba97 3 місяці тому +2

    I love your knowledge sharing but for this tutorial is not adapter pattern. It's strategy pattern combining to factory pattern. An adapter wraps one of the objects to hide the complexity of conversion happening behind the scenes. The wrapped object isn’t even aware of the adapter. For example, you can wrap an object that operates in meters and kilometers with an adapter that converts all of the data to imperial units such as feet and miles.
    Here you wrap anything

  • @rahuljagdale6690
    @rahuljagdale6690 3 місяці тому +1

    Hi Basant your video is nice but I think this is not adapter pattern this looks like Strategy pattern where we are selecting one strategy dynamically based on user input

    • @Javatechie
      @Javatechie  3 місяці тому

      My name is Basant not Hemant 🤣😂

    • @rahuljagdale6690
      @rahuljagdale6690 3 місяці тому +1

      ​@@Javatechiecorrected😂

  • @suminshakya5067
    @suminshakya5067 3 місяці тому +3

    Are you sure this is an adaptor pattern I think this is factory

    • @Javatechie
      @Javatechie  3 місяці тому

      Hello buddy could you please share some insights on adapter design pattern if it's not? I do mentioned it's combined of factory and DI injection

    • @mohammadshahruk8017
      @mohammadshahruk8017 3 місяці тому

      I also have same doubt

    • @Javatechie
      @Javatechie  3 місяці тому

      Not getting buddy how come it's factory design pattern ? Please watch the approach again and let me know

    • @universal4334
      @universal4334 3 місяці тому +2

      @@Javatechie this is not a factory for sure! But it has some sense of factory pattern.

  • @manoffewwords5982
    @manoffewwords5982 3 місяці тому

    Looks like factory design pattern