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
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!!
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 🚀
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)
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
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.
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
This is a great tutorial, and the explanation is straightforward. but the 'setStrategy method is called in the client code but this method is not defined in the 'strategy Service'
the first example also violate dependency inversion since the 2 class must depend on abstraction instead of each others .. reducing coupling between the 2 classes
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?
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!
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!
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?
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!
@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?
@zheenbekakimzhanov8969 At first glance, I had the same questions as you have. But as I was thinking about it more and more, I ended up with the following answer, at least for the specific example. Think of the different fields that you need on each separate strategy. Other fields you need for the payment using credit card, other fields you need using another strategy, etc. So I ended up with the solution that each payment button on the front end will call separate end point on the backend, cause of different DTOs. Then, each end point will make use of one and only one payment strategy. Hope this helps a little bit. 😅
The Strategy Pattern does also violate the O-C Principle. You can't add new behavior to PaymentStrategy like e.g. refund(int amount, ...) without modifying existing code, which includes PaymentStrategy and any implementing class. This is also known as the Expression problem. To my knowledge, the only solution that fulfills the O-C principle is the Object Algebra pattern.
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?
Hello, feel free to check our dependency injection video here: ua-cam.com/video/GATSXm7WAxU/v-deo.html. 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!
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 ?
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
With the help of @Setter from Lombok we made use of the setter injection. Feel free to check this video for more info: ua-cam.com/video/GATSXm7WAxU/v-deo.html. Cheers!
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: ua-cam.com/video/HoA6aZPR5K0/v-deo.html! Cheers!
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 ?
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 :)
Hello, you can find our Dependency Injection video here: ua-cam.com/video/GATSXm7WAxU/v-deo.html. Please take a look, and let me know if you are still confused!
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
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!!
I have seen almost all the design pattern videos on this channel. They are to the point, explain concepts with relevant examples. Kudos!
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 🚀
Thanks a lot for your kind words man! Glad you enjoyed it :)
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)
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
I do the opposite, first view the videos and then read the book you mentioned.
Awesome! You explained this brilliantly, we replacing abusing if statements with “client context” strategies.
Wonderful explanation. I also liked that you mentioned what principles it covers. Thank you :)
Great explanation! I've seen a few vids on the strategy pattern but this one definetly stands out :)
Thanks a lot! Glad you found it helpful :)
Its so unfortunate that I found your channel only now. Top notch explanation!
Really amazing content with real life examples. Good work (y) . Subscribed! :)
The interviewer was good. From low to high. ❤
Thanks for this video I didn't understand it at my university but now I understood all.
Thanks 😊 .
Bingo 😊 Thanks for the clear explanation.
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.
Happy to read it! Best of luck man :) If you need help let me know via the youtube mail!
I really like how you break this down.
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
This is really the best explanation.
Very helpful thank you!!
This is a great tutorial, and the explanation is straightforward. but the 'setStrategy method is called in the
client code but this method is not defined in the 'strategy Service'
Thanks for those very clear explainations 🙏
the first example also violate dependency inversion since the 2 class must depend on abstraction instead of each others .. reducing coupling between the 2 classes
amazing videos! great explanation, thank you very much.
Amazing Explaination Thank you
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?
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!
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!
Glad I could help! I auto-generated it online, but planning to change it soon. Can't remember the website name anymore xD
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?
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!
@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?
@zheenbekakimzhanov8969 At first glance, I had the same questions as you have.
But as I was thinking about it more and more, I ended up with the following answer, at least for the specific example.
Think of the different fields that you need on each separate strategy. Other fields you need for the payment using credit card, other fields you need using another strategy, etc. So I ended up with the solution that each payment button on the front end will call separate end point on the backend, cause of different DTOs. Then, each end point will make use of one and only one payment strategy.
Hope this helps a little bit. 😅
Great explanatio, Thank you.
The Strategy Pattern does also violate the O-C Principle. You can't add new behavior to PaymentStrategy like e.g. refund(int amount, ...) without modifying existing code, which includes PaymentStrategy and any implementing class. This is also known as the Expression problem. To my knowledge, the only solution that fulfills the O-C principle is the Object Algebra pattern.
Changing the payment type at runtime, this is an example of Dependency Injection. Right?
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?
Hello, feel free to check our dependency injection video here: ua-cam.com/video/GATSXm7WAxU/v-deo.html.
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!
came here looking for the exact comment
I think Factory pattern also can be maintained by the same strategy.
It's confusing. Both are solved quite similar purposes.
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 ?
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
Good Explain !
Best and simple example in the world
Thank you!
where is the setStrategy method defined in the PaymentService ???
Oops!
Please does the PaymentService implement the Dependency Injection either?
With the help of @Setter from Lombok we made use of the setter injection. Feel free to check this video for more info: ua-cam.com/video/GATSXm7WAxU/v-deo.html. Cheers!
@@geekific Thank you!
@@geekific Great explanation thanks again!
Is Strategy Pattern also an explanation of the Dependency Inversion principle?
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: ua-cam.com/video/HoA6aZPR5K0/v-deo.html! Cheers!
@@geekific "if you still depend on the implementation" What does this mean?
Doesn't every strategy class have its own implementation?
@@whogashaga Watch the video!
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 ?
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 :)
@@geekific perfect, thank you :)
Phenomenal!!!
Glad you liked it :)
What is the difference between dependency injection and strategy pattern?
Hello, you can find our Dependency Injection video here: ua-cam.com/video/GATSXm7WAxU/v-deo.html. Please take a look, and let me know if you are still confused!
anyone knows where the setStrategy method in main come from ?
this is excellent
Thanks a lot :)
3:46 your main class uses a setStrategy() method but there isn't this method on PaymentService class
There is a lombok @Setter annotation for the class which generates the setters for all of the PaymentService class fields :)
Life saver
Glad it was helpful!