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:)
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
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!
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.. !!!!
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
This was amazing! A colleague of mine used this pattern without using "visitor" in the name. I understood the structure and how to use his design, but I didn't fully grasp everything that was going on or how he even came up with it. He mentioned visitor and here I am. Thanks for the concise but real world example.
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.
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!
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!
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.
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 😅🤟!
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. :)
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 👍🏾
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?
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
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.
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
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.
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.
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
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!
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.
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.
@@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.
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.
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)
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.
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!
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.
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?
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?
