The Strategy Pattern Explained and Implemented in Java | Behavioral Design Patterns | Geekific

Support us on Patreon: / geekific
GitHub Repository: github.com/geekific-official/...
Stay updated on our videos by subscribing to the channel and hitting the like button!
Today, we add another Behavioral design pattern to our Design Patterns in Java series: The Strategy Design Pattern.
Timestamps:
00:00 Introduction
00:31 What is the Strategy Pattern?
02:30 Strategy Pattern Implementation
03:56 The Strategy Pattern Class Diagram
05:17 State vs Strategy
06:36 Recap
07:16 Thanks for Watching!
If you found this video helpful, check other Geekific uploads:
- Introduction to Design Patterns: • What are Design Patter...
- Object-Oriented Programming Fundamentals: • What is Object-Oriente...
- UML Class and Object Diagrams: • UML Class and Object D...
- The State Pattern Explained and Implemented: • The State Pattern Expl...
- SOLID Principles and Best Practices: • SOLID Design Principle...
#Geekific #DesignPatterns #StrategyPattern #BehavioralPatterns

[@benyameenashraf3142]

I seen so many youTuber to learn this pattern in 35 or 30 mint long videos.the funny thing they did not teach me in 35 mint which you just did in 7 mints. superb

[@MelissaBrown26]

God bless you. I was trying to read my textbook for all of these strategies and was ready to throw my laptop at the wall. This is simple to understand even for beginners. Thank you!!

[@kulrash]

I have seen almost all the design pattern videos on this channel. They are to the point, explain concepts with relevant examples. Kudos!

[@adamee007]

Its so unfortunate that I found your channel only now. Top notch explanation!

[@anuragtripathi6336]

Really amazing content with real life examples. Good work (y) . Subscribed! :)

[@gerardofranco4370]

Clear, simple explanation, great video! I would also add that this pattern not only applies the Single Responsibility and Open-Closed principles, but also the Dependency Inversion. By using this pattern you avoid that your high level modules (in this case, PaymentService) have dependencies with your low level modules (CreditCard implementation, Paypal implementation, Bank transfer implementation, etc)

[@adam.phelps]

Very helpful thank you!!

[@christopherreif3624]

I really like how you break this down.

[@lukasaudir8]

This channel is an amazing complement for the book design patterns, really great to see the patterns explained in video after reading about the details in the book, thank you

[@suleymanaghamoglanli4439]

I do the opposite, first view the videos and then read the book you mentioned.

[@rayunn3502]

Thanks for those very clear explainations 🙏

[@moisesdepaulodias7980]

amazing videos! great explanation, thank you very much.

[@mfiveer4283]

Great explanation! I've seen a few vids on the strategy pattern but this one definetly stands out :)

[@geekific]

Thanks a lot! Glad you found it helpful :)

[@jasper5016]

This is really the best explanation.

[@mukulkopulwar]

Amazing Explaination Thank you

[@tucanalfavorito6623]

Thanks for this video I didn't understand it at my university but now I understood all. Thanks 😊 .

[@mali_dev]

Great explanatio, Thank you.

[@fusionmantra3608]

thanks alot for this video i learnt this example from ur video and same question is asked in interview n they are impressed for it 🎉 thanks alot for the video

[@Ramkumar-uj9fo]

The interviewer was good. From low to high. ❤

[@sergiog114]

Fenomenal, as the other videos in the series. The fact that you gave context, explained differences and showed up an example in only 7:26 mins says a lot of your experience. Keep it up! You bring so much value into the community 🚀

[@geekific]

Thanks a lot for your kind words man! Glad you enjoyed it :)

[@Mohamed-uf5jh]

Good Explain !

[@vengateshm2122]

Very clear and pragmatic comparison with state pattern. May be I will spend a week to go through all your tutorials and take notes and then will attend interviews. Would like to know your profile.

[@geekific]

Happy to read it! Best of luck man :) If you need help let me know via the youtube mail!

[@mayankpratapsingh4241]

Thanks for such an amazing content. Could you please let me know how did you design the intro of this video ? Which app did you use ? Where can I also get such amazing videos for an intro ? Thanks in advance!

[@geekific]

Glad I could help! I auto-generated it online, but planning to change it soon. Can't remember the website name anymore xD

[@andersontiban5356]

Wow great video thanks, what are books or online resources that bridge the gap from “beginner” knowledge such creating a class, for loops , etc .. To best practices and design patterns ?

[@geekific]

Thank you! I don't have a single resource, before each video I try to look-up as much references as possible so that nothing is missed. So, our channel might be a good answer to your question I guess :P

[@prateek8837]

Changing the payment type at runtime, this is an example of Dependency Injection. Right?

[@markkogan7247]

Phenomenal!!!

[@geekific]

Glad you liked it :)

[@allopiccipolla8061]

Thank you for the beautiful video. I have a question if you do not mind. In the CONTEXT class, instead of making a field holding the strategy and implementing a set method to update the strategy ... could we just pass the strategy to the payment method as a parameter? Like: processOrder(PaymentStrategy ps){ ps.collrctio..... } What is the difference between the 2 implementations, is it wrong to do it this way ?

[@geekific]

Glad you like them! There is nothing wrong with the approach you can do that, however, if you have multiple methods depending on this strategy (and not just one like in the example we have) you will have to pass it to every single one of them. On the other hand, if you pass it via a constructor or create a setter for it, you'll just need it once, that's is why I went with this approach, but both are fine :)

[@allopiccipolla8061]

@@geekific perfect, thank you :)

[@ak-ot2wn]

3:47 - in the main function, you have to set the payment strategy anyways based on the user's choice of payment method. So you will have to have some logic (conditions) around choosing the strategy like you had in the initial code (if (creditCardPayment) { ... } else if (paypalPayment) { ... } ...). How would you elegantly deal with this?

[@geekific]

Depends on the context. If we take this particular example, and try to apply it on an order page of some website where you have icons for credit card, PayPal etc. and upon clicking on each icon the correct payment is selected. Then in the initial impl both icons would forward to the same nested-ifs, whereas with Strategy you won't have if's anymore as each icon will be tied to a strategy... Hope this answers your question. Cheers!

[@deep.space.12]

My confusion isn't with the state pattern. Rather, I am trying to understand how the strategy pattern is different from the factory pattern (different classes sharing an interface are created) or dependency injection (client creates object and passes it to the context). For the former, as a creational pattern perhaps the focus would be on the creation of subclasses of the PaymentStrategy itself, rather than its behavior? For the latter case, strategy looks exactly like a setter injection. But then dependency injection isn't a design pattern, right?

[@geekific]

Hello, feel free to check our dependency injection video here: kzbin.info/www/bejne/fXK3hIujbLx0rrc. And to answer your question, the factory pattern is focused on the creation of the object, not its behavior. You can have a factory that spawns 10 different sub-products, but all of these products share the same exact functionality with the same exact underlying implementation (with creational patterns we answer WHAT is the object to create going to be). However, Strategy, as its name implies focuses on HOW the object is going to behave, so I can have the same exact object, but given a certain strategy it will act in a different way then when provided with another strategy, even if both lead to the same result, but the underlying behavior is be different. Hope this answers it! Cheers!

[@yashwantptl7]

came here looking for the exact comment

[@Joel-do3oi]

3:46 your main class uses a setStrategy() method but there isn't this method on PaymentService class

[@SauliusKulakauskas]

There is a lombok @Setter annotation for the class which generates the setters for all of the PaymentService class fields :)

[@user-yy6dv7bc4b]

where is the setStrategy method defined in the PaymentService ???

[@geekific]

Oops!

[@zheenbekakimzhanov8969]

But even if we use strategy design pattern we still have to decide what strategy to use. In your example you say that we need to "find" the right strategy at runtime, but isn't it it the same if else statement at the end which we were trying to avoid?

[@geekific]

Depends on the front-end solution. Take a very simple example, a page with 3 buttons, each button will launch a different strategy :) But from back-end perspective u r covered! Hope this answers it!

[@zheenbekakimzhanov8969]

@geekific oh, I didn't actually expect a response 😅 Anyway, after reading your response now I have another question in mind. I get what you mean, and basically you say that every possible outcome should have their own separate functions or api endpoints and which one to use is up to frontend implementation. But I'm just stuck with the analogy you showed in the video where in the first place you showed if else statements and you said this can be avoided via the strategy pattern. But by using strategy pattern we did not "solve" the if else statement problem and the initial code was completely removed. We for sure made the code more modular and just said well now it is someone else's problem to make the if else statement. When it comes to the frontend which should decide what strategy to use buttons are good way to delegate the decision further to the user. But buttons are the only solution I can think of right now and I know that often we cannot use them. So do we eventually end up using the if else statements? Does that also imply that generally enums are bad because enums often represent what strategy to use?

[@bolliranadheer7824]

What is the difference between dependency injection and strategy pattern?

[@geekific]

Hello, you can find our Dependency Injection video here: kzbin.info/www/bejne/fXK3hIujbLx0rrc. Please take a look, and let me know if you are still confused!

[@SuperAnusha]

this is excellent

[@geekific]

Thanks a lot :)

[@miratechsolutions5777]

Please does the PaymentService implement the Dependency Injection either?

[@geekific]

With the help of @Setter from Lombok we made use of the setter injection. Feel free to check this video for more info: kzbin.info/www/bejne/fXK3hIujbLx0rrc. Cheers!

[@miratechsolutions5777]

@@geekific Thank you!

[@miratechsolutions5777]

@@geekific Great explanation thanks again!

[@whogashaga]

Is Strategy Pattern also an explanation of the Dependency Inversion principle?

[@geekific]

It could be, but these are two different things. You can have multiple strategies implementing the same interface, but if you still depend on the implementation then DI is not being applied! Take a look at this and let me know if you still have questions: kzbin.info/www/bejne/fqCkZ5SQhbdogZI! Cheers!

[@whogashaga]

​@@geekific "if you still depend on the implementation" What does this mean? Doesn't every strategy class have its own implementation?

[@geekific]

@@whogashaga Watch the video!

[@phybriso]

Best and simple example in the world

[@geekific]

Thank you!

[@nomad5849]

Life saver

[@geekific]

Glad it was helpful!