The Visitor Pattern Explained and Implemented in Java | Behavioral Design Patterns | Geekific
Вставка
- Опубліковано 4 тра 2024
- 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!
I've received over the years a lot of feedback stating that the Visitor pattern is one of the hardest to grasp. In this video, we detail and explain the Visitor Design Pattern and hope that it'll clear things up!
Timestamps:
00:00 Introduction
00:07 What is the Visitor Pattern?
02:11 Visitor Pattern Implementation
03:38 The Visitor Pattern Class Diagram
05:02 Recap
05:36 Thanks for Watching!
If you found this video helpful, check other Geekific uploads:
- Introduction to Design Patterns: • What are Design Patter...
- UML Class and Object Diagrams: • UML Class and Object D...
- SOLID Principles and Best Practices: • SOLID Design Principle...
- The Iterator Pattern Explained and Implemented in Java: • The Iterator Pattern E...
- The Strategy Pattern Explained and Implemented in Java: • The Strategy Pattern E...
- The State Pattern Explained and Implemented in Java: • The State Pattern Expl...
#Geekific #DesignPatterns #VisitorPattern #BehavioralPatterns
by choosing good example pattern suddenly becomes very clear, thank you
You have no idea how helpful these videos are! ❤❤
This explanation is very clear! Now I can finally understand this Visitor pattern thank to this video. Thank you!
Awesome, I finally understand how this pattern works, thanks.
hi, I am been programming for about 300 years,
no just kidding 😁, for 30 years.
I must say "well done sir"
my question for you: where did you get your knowledge please? which books, or through experience and coworking with others?
thank you for your accurate and professional videos.
Hello :) Thank you, this really means a lot especially from someone like you!
Concerning your question, it is actually a mix of everything there no particular reference or book that I stick to, I usually pick a certain topic and intensively research it before making any video just to make sure that everything that needs to be covered will actually be covered. Even if I already know a lot about this or that topic, I still do the research and try not to stick to one reference, or one perspective, this helps in covering a few gray areas in stuff I already know or areas that I didn't even knew existed!
@@geekific
👍
Thank you so much for this very helpful tutorial ! 🙏🙏🙏
Wow thank you sir for great explanation... This pattern always confused me but your video makes it clear.....
Great video. Thanks for the clear explanation!
Glad it was helpful!
Quick to the point and easy to understand. Kudo
great explanation, thanks
very good explanation. Thank you for your effort.
You are welcome! Glad it was helpful!
Hi, thanks for great explanation.
just wondering at 2:59 your Visitor Interface consists of methods with name void visit(Bank bank) , void visit(Company company) ... etc
but jump in to your example at 3:25 , the method in Client concrete class(Bank, Restaurant, Resident) inside their method void accept(Visitor visitor) it become visitor.visitBank, visitor.visitRestaurant ... etc instead of just visit as previous Interface. could you explain why these two are different ?
Really useful!!!!
AMAZING
Thanks for the video, it's really helped 👍 It's interesting that for each concrete element you might need an individual method in the Visitor interface. I guess this would only be suitable if you don't expect too many concrete elements or they could largely be operated on the same?
Glad it was helpful! True, the whole idea behind the visitor pattern is to place new behaviors into a separate class instead of trying to integrate them into existing classes.
very very good explanation. Thanks so much
Glad it helped!
It was very helpful indeed
Thanks man! Am glad it was :)
Super!
this pattern is similar to sharing food with younger siblings. they always say I got less portion.
you give food to them and ask them to choose your portion and give it to me.
amazing explanation the only thing i would do is to separate the accept method from client interfae for interface segregation principle and single responsabilty apart all was amazing
Thank you
is it possible that you can explain this further?
Could you elaborate more on how not using the visitor pattern was breaking the open/closed principle? I still think that this wasn't the case since classes were already extendable without modifying them, which is the only concern of the open/closed principle.
In this particular example, if you were to change the "sendMail" functionality, you will have to open all the created classes and modify them.
I'm a bit confused by the open-closed principle. Here, we can modify the class ConcreteVisitor and the interface Visitor if we need to add new specific methods for the clients. But wouldn't we be breaking this principle? From my understanding of previous patterns, we added classes, so we didn't need to modify existing ones...
I was thinking the same thing.
I have a question about the method implemented in the ConcreteVisitor object. How can it access attribute from ElementA object in the visitA method?
Hello! The visit methods implemented in the ConcreteVisitor class take concrete elements as parameter and not the interface, this way they will be able to access stuff specific to that element :) Hope this answers your question! Cheers!
Is there an example of where accept would be implemented differently for each Element?
If you have pre-stuff specific to that element you want to do, yes... In this simple example we are just calling the visit method, and yet each time we call a different one...
can you build a project in which you could incorporate all the 23 design patterns.. that would give a better complete compiled understanding.. :)
Great idea! Not easy to come up with though :P Will keep it in mind for future videos! Stay Tuned!
@@geekific turned on the bell icon :)
that project would need to be massive
i find this weirdly similar to mediator pattern. both address the possibilities of invading dependencies' privacy and the object's single responsibility principle.
obviously they are different in implementation. the mediator sits inside the class whereas visitor is nothing more than a function parameter being passed in.
but on an abstract level i just find them awfully similar.
Both are Behavioral Patterns concerned with communication and assignment of responsibilities between objects as the program is running. That is why you will find similarities :)
I still did not get it. If i need to change the way the mail is send for a resident, i'll need to go to the visitor and update, the same is true in case of the original design where i'll change the sendMail behaviour. If i am creating multiple visitors like send mail and another which is give promo, I'll need two different function in the client to call the correct visitor. How is this any different from the initial class structure?
In the initial structure, if you want to modify the behavior of your classes (the 'sendMail' functionality in this case) you'll have to open and break each and every child class you have. After applying the Visitor pattern, the only change you need to make will be inside your visitor, your classes are now closed for modification but open for extension. Hope this helps!
Why isn't the overloading mechanism able to resolve the client-type at runtime?
Because we'll be passing the interface and not the implementation
This seems like it just moves the problem around. Isn't the Visitor interface now open for modification? Every time you want to add a new type of element, it needs to be changed, and so all concrete implementations need to be changed as well.
The centralization is key here. By "moving stuff around" we are now able to extract common behaviors and work based on a single source of truth mentality. Remember, design patterns are about organization and laying out a series of steps to follow, we are not trying to modify the core logic.
@@geekific Thank you for the reply, but I'm not sure you understood my comment. I wasn't talking about moving methods around, but moving the problem around. Specifically, you solve the violation of the open/closed principle in the Clients (you don't have to update the client classes every time you add new functionality), but you create a new violation of the open/closed principle in the Visitor interface: every time we add a new type of Client, we need to add a method to the Visitor interface, as well as all of the concrete Visitor classes.
@@atrus3823 thanks for raising this point. The goal shifting is indeed occurring. So clearly the tradeoffs need to be discussed before going ahead and over engineering something.
To me Strategy pattern seems to be a better fit for the mail example..
But i guess with this pattern we can have multiple types of visitors without modifying anything existing
💪
Combining data with functionality is the whole point of OOP.. The "Single Responsiblity" principle is greatly misunderstood.
Watch our video on SOLID principles here: ua-cam.com/video/HoA6aZPR5K0/v-deo.html! Cheers :)
Same with open-close principle. As long as the declaration in abstract class remsins the same (namely, "sendMail()" remains the same, not renamed, no arguments or return values are added), changing the implementation is not a violation of O in SOLID. In fact, we put the method here so the logic corresponding to this object only would remain near it and unavailable to any other entities within the program.
agree with you, one thing the author doesn't address is that visitors can;t access the private data of each of the client implementations (visitables) and hence data has to be made public thus violating information hiding. visitor pattern is complex.
are you lebanese?