Let me know what design patterns you want to learn!
@TheSimpleEngineer5 жыл бұрын
@@dg10mcdos cool 🙂 I'll do that one next
@hinathahseen86435 жыл бұрын
Thanks for the above one. Double dispatch couldn't be simplified more.Can you t explain examples of Extension object and Template method design pattern:)
@mirazzaidi5 жыл бұрын
Can you do a decorator?
@deepankarsingh72305 жыл бұрын
Can you please make a video on strategy design pattern?
@Nemecis3135 жыл бұрын
I would like to understand the Mediator design pattern if possible. Thank you for this video!!
@mehmeterdem75815 жыл бұрын
This is probably the best video on the net for this pattern with a perfect example.Thank you!
@illosophycom5 жыл бұрын
Isn't this still tightly coupled though? If you get rid of the Bronze Card or add a Platinum card, you have to update your OfferVisitor interface and all of the classes that implement OfferVisitor right? That's still a maintenance nightmare. It seems like the problem wasn't solved but just relocated.
@TheSimpleEngineer5 жыл бұрын
There will always be some coupling, but the amount is reduced as your class base grows large.
@ruixue69553 жыл бұрын
2:50 UML dia of Visitor Pattern 4:20 the original piece of hierarchy 6:50 why - single vs double dispatch 7:39 single dispatch 8:14 what single dispatch allows us to do 9:58 double dispatch: interaction of 2 objects 10:12 example 10:28 modify the interface: in Animal interface, add makeSound(Dog) and makeSound(Cat) 11:45 *compile error* due to not support on double dispatch
@usamakhawaja85715 жыл бұрын
Just half way through the video, and I would like to say "Good Job". (y)
@maciejkowalski30195 жыл бұрын
ok, but what if you have created hundreds of different visitors and you have to add a platinum card?
@SylvainBrunerie3 жыл бұрын
Great explanation, thanks! My question is the following: we made CreditCard easy to extend without needing to modify it, but now OfferVisitor kinda is in the situation we wanted to avoid, right? If we create a new PlatinumCreditCard, the OfferVisitor will have to define visitPlatinumCreditCard, and all the visitors will have to implement it. It feels like we need to take a guess at which side (credit card or offer) is more likely to be extended in the future, and use a visitor pattern for that one. But we can’t have that for both of them. Is that right?
@rolandsoftwareguy25153 жыл бұрын
I think the idea is you might add a card once or twice a year but maybe 3 or 4 offers a month. I guess what we would normally to is have a GetCashBack(CreditCard, Offer) method but then there would be the overhead of maintaining a datastore
@GiorGoS070319922 жыл бұрын
I think so like the a scenario like the one described on this video. You don't come up with new credits cards every day, but you may get new offers every day/month.
@genovo3 жыл бұрын
Problem: 12:56 Solution: 28:00 Fantastic video!
@deepankarsingh72305 жыл бұрын
Amazing explanation. I like discussions a lot when it cover the background as well like why something is needed, current limitations in some paradigm and ways to solve that. Thanks a lot for the video. :)
@rahulsaxena91033 жыл бұрын
He has made the pattern as easy to understand as hard it is going through other explanations on the web. Amazing!!
@atanubanerjee33894 ай бұрын
Hi Ryan - so could you please tell how I apply Visit/Accept pattern to resolve the original problem of cat-bark or dog-meow you originally started with ? Should I create one more class like CATDOG from Animal, accept runner request and forward to makeSound Visitor - visit(CATDOG). Or simply type-check a => in Dog "makeSound(Animal a)" for Runner request of "dog.makeSound(cat)" and take action . Much appreciate and thanx.
@ashrasmun15 жыл бұрын
I would love to see constructive criticism from someone who disliked this video. I think it's unbelievably helpful, especially given that you explained the whole "dispatch" thing, which is not obvious at all for beginners. Thank you very much!
@TheSimpleEngineer5 жыл бұрын
Thanks, glad you liked it!
@piotrpieniak7385 жыл бұрын
I'm so grateful for it, good job! I always struggle with theoretical explanations and definitions, so combining them with actual examples made it so much easier to understand.
@williamquintero31333 жыл бұрын
Excelent bro... i've just spend a lot of time trying to understand this patterm. And you did it in just 30min :) thanks..
@tinker7722 Жыл бұрын
Thanks for that brilliant tutorial! Actually, "accept" is calling the visitors visit function, isn't it?
@ArchaeanDragon10 ай бұрын
GoldCreditCard silver Had no effect on the running code, but boy did it trip my OCD! lulz :P I think it would have done better to drill into why you couldn't pass cat to itself. Basically, you can't pass ancestors references into descendant params and vars. The compiler gives you that hairy eyeball because the running app can't use a crystal ball to figure out which descendant you meant. I think it was part of your higher-level explanation, but for newbs, the underlying problem wasn't as clear.
@ben63 жыл бұрын
This was the best resource I've found so far, but unsurprisingly, I am a bit confused. First: I guess we need to write a new `accept` method for each type of resource (e.g. offer) that Element can take (in this case, Bronze, SIlver, Gold credit cards.) We are not able to share `accept` methods between concepts: e.g. Not just offers (hotel, gas), but also other behaviour, like update state, get description, expiry. Could someone suggest a better name for accept? Second: The video author also wrote 'visitBronzeCreditCard' instead of just 'visit', so this actually goes around the problem of (not highlighting how visitor patterns overcomes lack of double dispatch)
@sergeyt41183 жыл бұрын
am I missing something? - this very much reminds me of a simple and well known MS Excel's LOOKUP() function - which solves to find an intersection of column and row in a 2d matrix based on input parameters (without any programming) - if I'm right, why would anyone want to re-invent the wheel and use such complex patterns if you could just refer to the respective MS assembly logic in c# (or maybe there are alternatives or code that does this thing outside excel boundaries) and just use this algorythm?= to me any code that cannot be logically and transparently walked-through step-by-step by a human is dangerous in its logical design; I hate OOP for such couter-intuitive constructs where the compiler does its magic and you just have to hope your tests will prove it brings the correct result and does not make mistakes in all possible input scenarios; I think in cases like this coders like mathematicians went a little over the edge
@shekhar_20143 жыл бұрын
Can you please make vdo on Builder, decorator, Abstract factory patterns ? Thank you
@thesuperiorman83423 жыл бұрын
You've appropriated this example without attributing it to the original creator. Pathetic Source: www.javagists.com/java-visitor-design-pattern
@kinvain3 жыл бұрын
Really like your video. Especially that you extend fake Animal interface use case to something more realistic.
@ksaisko2 жыл бұрын
I don’t understand how you can access attribut of the object accepting a visitor inside the visitor function, isn’t a problem?
@kaustuvchatterjee41172 жыл бұрын
This problem can be solved using decorator pattern also.. What is the subtle difference?
@mysteriouse5891 Жыл бұрын
Very generic and common example. Does not attempt to show an actual interaction between the visitor work object and model data object. Printing lines is pedestrian
@herrgrillparzer3 жыл бұрын
Such a clear explanation and great examples. Thank you so much for this 😊
@coffeeandbytes98542 жыл бұрын
Super load intro music followed by super quiet microphone.
@houssemzaier4 жыл бұрын
I hate this DP for its non-semantic approach. You should fight against it if you are a kotlin user the language give you tools to skip this overhead, using the sealed classes you can do more with less code.
@mrowox10 ай бұрын
This is really fantastic. Is it possible to combine this pattern with the Factory pattern for example to dynamically determing which credit card to use in a certain scenario
@yolokazinogantsho81113 жыл бұрын
Great great great explanation. Totally understood! Big thanks
@pm58283 жыл бұрын
Thank you for the great video! can we use Async/Await with visitor Pattern since what i intend to do in visitor is make outgoing calls.
@reallylordofnothing Жыл бұрын
really good video. came here to understand rsql-parser visitor pattern. I can see that this pattern explains open closed principle very well
@whatever62232 жыл бұрын
Excellent explanation. Thank you very much!
@AB-os3jy3 жыл бұрын
it would be a hit if you could do a series or video that puts together and deploys a multi platform mobile app. bonus if it has animation , audio and 3d capability.
@chiranjeevisaride86553 жыл бұрын
The best explanation anyone can find on this planet. Absolutely loved it!!
@ilstam99425 жыл бұрын
Awesome explanation and helpful example! I hadn't realize before about the double dispatch problem. I really liked that you didn't over-explain things keeping it short and to the point. Also thumbs up for cutting out the tedious parts where you just paste code. Thank you!
@jonathankee93222 жыл бұрын
At around 13:00, we could have used instanceof and casting to get the correct Cat or Dog object though?
@FernandoNavarro_13 жыл бұрын
Very clear presentation and illustrative code. Thanks
@michaeljuergen43263 жыл бұрын
Very good explenation, this is the Video I was searching for the whole time
@kartech45922 жыл бұрын
Can we say one drawback of this pattern is that the visitor needs to have a visit method for all card types even if it might not apply to that card? Is there a way to overcome this necessity?
@mirazzaidi5 жыл бұрын
Great explanation! I am just wondering why you didn't overloaded the visit method in Visitor interface with Concrete element parameters and created 3 separate methods for each method.
@lucykuo47695 жыл бұрын
Finally found a great video for visitor pattern! Hope you can make more design pattern tutorials
@rajeshtc89655 жыл бұрын
If one more card type is introduced, then offervisitor interface need to be updated with one new function which support new card type right?? Is this violate solid design principle??
@ihormay34184 жыл бұрын
yes, you need to implement new method. But only ones. But your can add new visititors with new card withour changing new methods. So, yeah, it's kinda violite solid principle in a some way, that's why Common Lisp is definetly better in this current situation. But if we use java/c++ we should accept this drawback, nothing we can do, basically. (Not talking about c++23 code generation possibilities)
@TheFrogfather1 Жыл бұрын
Nice clear explanation. Thank you!
@TommyBoy7Heads2 жыл бұрын
Legend.. thanks for the great explanation man.
@kankipatisaikumar3 жыл бұрын
@the simple engineer Great explanation, easy to memorize
@LemmeTellMe5 жыл бұрын
Good job on the video, heads up though the intro music could be tuned down a bit since it feels a lot louder than the rest of the audio
@ambarishkapil80043 жыл бұрын
This was very nicely explained. Thanks
@luyandamsomi84022 жыл бұрын
great job man, really appreciated💪👏
@ashrasmun15 жыл бұрын
I recreated your examples in C++ and they just work without the visitor pattern... I am super confused. I have classes "Duck" and "Chicken", deriving from "Bird". They all have a method "greet" and this code compiles and works just fine. Bird* d = new Duck; Bird* c = new Chicken; d->greet(c); This seems contradictory to what you've said around 13:30.
@MirekKrenc2 жыл бұрын
Very well explained. Thanks!
@mireazma4 жыл бұрын
The way I see it visitor pattern doesn't make you write any less code but it gives the advantage of decoupling. But even so, it kind of does and then it doesn't. In the "multi-dimensional" case like cards/offers it all depends on which of the dimensions you're likely to have more classes added. Even if card types are issued occasionally, for every new card you have to make modifications in every _offerVisitor_ . And there may be an order of magnitude more _offerVisitor_ classes than cards because that's precisely the case that visitor pattern tries to mitigate - many offers, few cards.
@lascau29184 жыл бұрын
@mzma You are right but what if both cards and offers increase drastically what is the solution/pattern such that you obey the O from SOLID?
@mireazma3 жыл бұрын
@@lascau2918 Not only O but I as well. Think about the case where a credit card only has certain offers or there's an offer that only applies to certain credit cards (it depends on how you look at it). The key is not enforcing all combinations, i.e. not enforce implementation of all those interface methods. I'm thinking we could modify the visitor part a bit. Abstract out individual card-offer combination into something like _Interaction_ that would have an _interact()_ method that does the calculation . _OfferVisitor_ would have a _List_ . I haven't thought this through but the idea behind this more complicated structure is: 1. Each new card doesn't imply modifying all offers. 2. Only have implementations for actual card-offer combinations, and not also for nonexistent combinations.
@natanloterio3 жыл бұрын
Great video. What pen table + software are you using? Wacom?
@TheSimpleEngineer3 жыл бұрын
Wacom Intuous
@saurabhchaturvedi69823 жыл бұрын
Awesommest post on the internet on Visitor Design Pattern !! Understood everything in such a simple way that its gonna stuck in my mind forever !! Subscribed !! Thank you..may you have many more "Visitors" on your channel 😅🤟!
@sagaragrawal8935 жыл бұрын
One small question - The GasOfferVisitor has 3 methods for the 3 types of credit cards. What if GasOffer is not applicable to Bronze Credit card? So in the GasOfferVisitor class you may remove that method pertaining to Bronze OR throw an exception from there? Whereas from the main method, BronzeCard would still be okay to accept GasOfferVisitor object as an input param at compile to only get a runtime exception or empty response. How can this use case be handled?
@andres57092 жыл бұрын
i'm no kidding there's a job offer in play here, and I have to deliver a code using this very pattern and i couldn't get it before watching this amazing explanation of yours! thank you for time and help from Brazil!
@256sks3 жыл бұрын
Thank you for good explanation. Your final implementation require small correction. Visitors classes should have overloaded method rather than different name for different CreditCard. Otherwise it will work without double dispatch.
@Rastrigin3 жыл бұрын
great job man, love your setup as well
@PrashantGangwar2 жыл бұрын
I've seen lot of videos on this pattern but this is most real life understanding video on Visitor pattern, Thanks for this amazing video... luckily found this
@aelafdev3 жыл бұрын
by far much cleaner explanation. visitor is mystrio no more. thank you
@MN7Editz3 жыл бұрын
Very good explanation. So far the best explanation and presentation on this pattern and finally I got it understood. Thank you very much.
@eliyahuspeyer1696 Жыл бұрын
your wonderful! thank you!
@rolandsoftwareguy25153 жыл бұрын
Excellent explanation especially of the why. A lot of tutorials just go straight into the how. I think given the extensibility problem, I might have initially gone down the passing of delegate route or maybe another interface - but I guess this seems somewhat tidier. Note to any other C# Developers reading before watching, the video is still easy to follow. Well Done 👍🏾
@atamanson4 жыл бұрын
Thanks for the awesome videos. Would you say Visitor pattern is suitable for basket/cart system ?
@peacefulwater96893 жыл бұрын
very good video, explaining single vs double dispatch really cleared it up. The only thing I didn't like was the intro
@fakhrshaheen33945 жыл бұрын
very well explained.it's really one of the most underrated patterns
@gunjanchaudhary97162 жыл бұрын
The best Explanation !
@dhapategeetanjali7414 жыл бұрын
I wonder all over the internet to find the best to learn visitor design pattern and finally landed here and writing comments middle of the video, This is an awesome video so far I came across. Buddy keep it up you are the best.. !!!!
@ruixue69554 жыл бұрын
1:08 visitor pattern 2:48 UML
@kushal800 Жыл бұрын
best video. love from india
@zizimouad82912 жыл бұрын
THE only video explain this pattern in the right way ! explination, diagramme and exemple with code all are perfect
@samitabbakh84092 жыл бұрын
Really nice explanation. I hope you would do a complete playlist of all design patterns. It is a shame that you made only 3 design patterns.
@kitkarson42263 жыл бұрын
This is good explanation. But how does it support open closed principle? You need to update the OfferVisitor interface to include if we introduce a new CreditCard type - say Platinum card. Basically we move this from one place to another. The original problem is still there.
@ShaunStruwig Жыл бұрын
There's essentially a trade off between type extensibility and extensibility of operations. So this pattern assumes that your types will be the closed set and you will only add more operations as time goes by as your open set. If you wanted to add more types it isn't the best choice of design pattern. So it supports Open Closed principle only in extensibility of operations but not types.
@kitkarson4226 Жыл бұрын
@@ShaunStruwig It took some time for me to realize that.
@dispatch34993 жыл бұрын
He is using vim inside intellji😍
@sv31673 жыл бұрын
Wow, pretty legit!! I understand!! Thanks a lot!
@MrJonnis133 жыл бұрын
Simply excellent explanation of this design pattern. As you said, this one is underestimated but it is super useful. Please consider doing some other design patterns, especially the "not easy" ones Thanks again for this video
@jaydenhooper2 жыл бұрын
Excellent explanation!
@deltaphilip86113 жыл бұрын
Finally make sense. Knowing what to accomplish makes it easier to understand how to do it
@ruixue69553 жыл бұрын
14:07 example of double dispatch (faking) - visitor 14:23 - 17:46 18:57 the concrete visitor: GasOffer, HotelOffer ... 19:32 CreditCard interface code 20:32 OfferVisitor 23:37 GasOfferVisitor
@atulsaxena42864 жыл бұрын
Very nice videos probably the best on the internet. Please do other patterns as well with the same kind of explanations you have done in these videos. Thanks.
@DigitomProductions5 жыл бұрын
Thanks for this video. Life saver :)
@allen0hu3 жыл бұрын
WTF this is so well explained! Thanks, saved my finals :)
@AlbertoGS19905 жыл бұрын
You are the best explaining design patterns. You should make a single video for every single pattern in the book. Thanks a lot for your teach.
@andrewprotasenya74693 жыл бұрын
thank you very much, I finally understood the essence of this pattern
@simoncatteau28793 жыл бұрын
Very clear video!
@KeillaSellay3 жыл бұрын
Intro music sucks
@adamblance33462 жыл бұрын
Thank you! So many other videos on this feel rushed and don't go into enough detail.
@martinx38564 жыл бұрын
Good job, nice voice
@rezasaidafkan86983 жыл бұрын
Crisp! Good job!
@Sss222ddd Жыл бұрын
Wow thanks man
@billuchoudhary44363 жыл бұрын
What app u r using?
@bimarshsharma75563 жыл бұрын
Thanks for the clear and straightforward explanation.
@rohitupadhyay99644 жыл бұрын
Awesome tutorial, thanks very much.
@agatalach28554 жыл бұрын
This is a great video. Super clear explanation, great example, and the whole video was really well done. Thanks so much for your work, it's really helped me understand the pattern and I am now going to go check out your channel for more content, which I'm sure will be as good :) thumbs up!
@HassanBadir5 жыл бұрын
damn, this is well explained, when I look for a new topic to study I usually run through multiple videos until I understand it completely, this time i watched the whole video once and got it on first time this was amazing thanks a lot man, big like!
@dattatreykulkarni64724 жыл бұрын
Good Job Bro!!!
@ivannav4 жыл бұрын
Great job!
@amitsamratmaurya31704 жыл бұрын
Best content so far!! You won't need to read anything else after watching this.
@ArvindDevaraj14 жыл бұрын
very clear explanation of visitor pattern with real world examples