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!
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 ?
great video In the diagram at 3:55, the visitor interface should not have the functions visitA(ElementA) , visitB(ElementB) , rather it should have visit(ElementA) and visit(ElementB) 🤔, similiarly for the concreteVisitor I think both are okay @geekific can you please suggest which pattern to follow or what is the industry standard? (visit or visitA)
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...
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.
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.
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...
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!
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.
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!
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
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 :)
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.
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.
As per my understanding, That's true that Combining data and functionality is the whole point of OOP but the functionality should be associated to the domain in which it resides. Sorry but I am kind of correlating it with the Domain Driven Design, Sending email involves third party integrations and many low level details so I think sending email is not a domain behavior but it's a separate functionality and It don't fit in the Client object shown in this video.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Explained very well by
"why visitor? "
"how reach to visitor ?"
Good Approach !!!!
by choosing good example pattern suddenly becomes very clear, thank you
You have no idea how helpful these videos are! ❤❤
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
👍
This explanation is very clear! Now I can finally understand this Visitor pattern thank to this video. Thank you!
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 ?
very good explanation. Thank you for your effort.
You are welcome! Glad it was helpful!
Great video. Thanks for the clear explanation!
Glad it was helpful!
Wow thank you sir for great explanation... This pattern always confused me but your video makes it clear.....
at 3:19 , from the Bank class you are calling visitor.visitBank(this),
but there is no such function,
the declared function was visit(Bank bank)
great video
In the diagram at 3:55, the visitor interface should not have the functions visitA(ElementA) , visitB(ElementB) ,
rather it should have visit(ElementA) and visit(ElementB) 🤔,
similiarly for the concreteVisitor
I think both are okay
@geekific can you please suggest which pattern to follow
or what is the industry standard? (visit or visitA)
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.
Quick to the point and easy to understand. Kudo
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.
Thank you so much for this very helpful tutorial ! 🙏🙏🙏
great explanation, thanks
Sir adding a method accept() in concrete class like Bank.., is it violate OpenClose principle?
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.
It was very helpful indeed
Thanks man! Am glad it was :)
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...
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
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!
very very good explanation. Thanks so much
Glad it helped!
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 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!
Really useful!!!!
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?
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 :)
Thank you
Super!
AMAZING
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.
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.
As per my understanding, That's true that Combining data and functionality is the whole point of OOP but the functionality should be associated to the domain in which it resides. Sorry but I am kind of correlating it with the Domain Driven Design, Sending email involves third party integrations and many low level details so I think sending email is not a domain behavior but it's a separate functionality and It don't fit in the Client object shown in this video.
are you lebanese?