Excellent example of simplifying code - thank you! One of the barriers to my adoption of type-based pattern matching goes back to the earliest years of C#, when I was advised to use reflection sparingly. Pattern matching, or in this case type-testing if you will, is a form of reflection. It is evident that C# reflection is much faster than in the old days.
The visitor pattern helps processing complex tree structures. But yeah, that requires a tree structure first. People in compiler programming use visitors to translate program code (syntax tree) into machine code. Or you can replace flawed domain models using such a translation technique via fluent api syntax trees as well. I think the visitor pattern is still a powerful pattern for trees.
I love it!! I didn't know that Visitor Design pattern was function pattern.
ปีที่แล้ว +1
Well, in traditional visitor compiler won't capture "a new class" error because the domain class hierarchy is required. Compiler will generate a call to superclass Accept method. No compile time, no runtime error will occurr, heavy debugging time...
Many design patterns are way easier to implement with functional programming. Strategy is just a function with the specified signature (params and return). My only complain here is that languages like Rust would not need the _ => wildcard for the matching pattern, since implementing all subtypes is already exhaustive in my opinion.
Quite effective video! I like the "fluency" or how well the writing code is aligned with the talk. The first thing that comes to me is to check if there's some analyzer that can ensure exhaustive pattern matching at compile time, perhaps that is good fit for larger projects?
I think the compile time error is a pretty big difference. I don't' know as its worth all the complexity and boiler plate just to prove its well-formed, but it is a difference.
That difference is important in sensitive portions of code, like tree transformation visitors, library code, and similar. Take ExpressionVisitor in C# as a good example. It is virtually unimaginable that someone could transform expressions in .NET using any approach other than implementing the explicit visitor. On the other hand, most business applications do not have that problem. You would model business concepts as they appear and then define mappings to other concepts for years. Practice shows that adding variants to a business concept happens so rarely that you can safely ignore the nuisance that comes with that. How hard can it be to augment mapping expressions for a domain type once in two years? That is how often that happens! Of course, there are certain prerequisites to making it work that way. For one thing - discipline, discipline, discipline. Make every concept a small one. Build larger concepts by applying composition to smaller ones, not by deepening the hierarchies. Avoid hierarchies more than one level deep. Any hierarchy deeper than that must come with a rock-solid justification.
@@zoran-horvat Just pointing out to viewers that the OO version is solving a 'harder' problem, it isn't just verbose for the sake of it. The real question is do you have this problem and even if you do, is it worth this price to solve? Probably not.
This approach saves on complexity in the implementation but requires a special tool/testing to ensure correctness before deployment. It would be nice to be able to instruct the compiler that a type matching switch statement must be exhaustive over the derived types. Though it is probably not hard to write an analyzer for that.
I think the main benefit for the visitor pattern is when you expect others to write their own visitors to walk your (sealed) composite structure. In LINQ there is an abstract ExpressionVisitor that you could use to translate the Expression to whatever you like, using whatever you want. You could ofcourse still opt for pattern matching instead when walking the Expression object but why would you if you could just have your class inherit from the abstract so you get all the different types in their own method with autocomplete from your IDE? This does seem like the sole reason for this pattern to stay around in C# however.
That is an interesting suggestion. I will consider it next time, though it has a drawback that it is telling out the implementation detail. But I see your point and I will give it some time of thinking.
I think the visitor pattern plays well with java sealed class hierarchies. It would be nice to have something like that in c# as well. It's a powerful feature on its own allowing for example exhaustive enum like hierarchies similar to rusts enums. For the "implicit visitor" in particular it allows for a exhaustive switch without an catch all and giving you an compile error once someone adds a class to the sealed hierarchy.
Between the traditional visitor and pattern matching approaches is there any significant performance difference? Is the pattern matching just compiler magic that is type checking under the hood (which you could do in older c# direct with “is” and cast) which is slower than a polymorphic call?
original visitor design pattern can leverage dependency injection? Given the functional pattern matching approach lacks of it that could mark a difference
If we remove the "pattern matching" in the "implicit visitor" we'd have a "type checking" analysis into that method, Which would smell, and be a little confusing because besides, the proposed "implicit visitor" pattern looks more like the "factory method" pattern than the "visitor" pattern. That's my doubt.
Type matching expressions are the basis of working with discriminated unions in functional programming and discriminated unions are the basis of domain modeling. It is interesting to note that the Visitor pattern is adding this technique to object-oriented languages, whereas that same technique is supported natively in any functional language. Therefore, the Visitor was introduced to overcome the native deficiency of OOP. As C# gains more functional elements, pattern matching, including type matching, will gain more and more prominence. Regarding code smell: it could turn into a code smell if target objects were mutable. In an immutable design, it is a mapping like any other.
@zoran-horvat Thank you very much for the demonstration of the visitor pattern, excellent work keep them coming, one question about the names, in most systems you get the names from a database or an API and then you map them to a single DTO like `Person` record but in your solution, you have 3 records `SimpleName`, `Mononym` and `CompoundName`. and for the pattern to work you need multiple DTOs to work How would you resolve this problem if you want to implement the Visitor pattern?
For reference: th-cam.com/video/tq5ztZO45-g/w-d-xo.html The thing you need to ask yourself is whether the receiving party of your API cares which type of name the person is using. The visitor in this example is meant to return a string representation of the name object, regardless of its type. So your DTO, or receiving end would simply have a string property. In this case traffic would be one way and you would need a different approach if you were to ever allow creating or updating of the names. The Author API would probably care a lot about the types of names, but in the publications/books API you simply want to know the names. You could also change the return type of your visitor, exploring a different pattern/approach altogether might in the end be better.
The idea of needing to know/remember to implement code somewhere else (along with nasty switch/if class type checking and exception throwing if it does not exist) once a new class implementation is added to the solution has always felt wrong to me. Its not something I personally would do with the only exception being if I was trying to extend existing classes which reside inside a third party library and even then I would probably do it a different way.
Here is the answer I have already posted on a similar question: The problem of having or not having compile-time safety is important in sensitive portions of code, like tree transformation visitors, library code, and similar. Take ExpressionVisitor in C# as a good example. It is virtually unimaginable that someone could transform expressions in .NET using any approach other than implementing the explicit visitor. On the other hand, most business applications do not have that problem. You would model business concepts as they appear and then define mappings to other concepts for years. Practice shows that adding variants to a business concept happens so rarely that you can safely ignore the nuisance that comes with that. How hard can it be to augment mapping expressions for a domain type once in two years? That is how often that happens! Of course, there are certain prerequisites to making it work that way. For one thing - discipline, discipline, discipline. Make every concept a small one. Build larger concepts by applying composition to smaller ones, not by deepening the hierarchies. Avoid hierarchies more than one level deep. Any hierarchy deeper than that must come with a rock-solid justification.
@@zoran-horvat I agree that in reality adding another implementation may be infrequent or never happen but it still feels sloppy to me. I would say there is a case that the matching approach in the video breaks OCP but even I would say nothing is ever perfect and there could be times where breaking a SOLID rule(s) might be ok. Anyway, I'm really enjoying your videos - you're a very clever guy who deservers more subs/views.
The fact that this is not checked at compile-time creates an unnecessary cost, and a cost which is atypical for functional-style design. An unreachable exception is just a run-time crash for something you failed to check at compile-time, and should be considered a code smell. This seems to be a symptom of squeezing a functional pattern into an object-oriented context. A functional language would have PersonalName as a sum type, and so it could be checked at compile-time if all the summand types are handled in pattern matching. I'm not sure that this is impossible to check for the class hierarchy of OOP, but it's clear that C# at least isn't interested in doing that check.
Everything you said is right - to a point. By requesting compile-time safety, you are dismissing entire programming languages. C# is going this path for the last 15 years already and you can expect that all remaining deficiencies in its current state are temporal.
@@zoran-horvat I'm not trying to be a stickler about compile-time checking everything. I will always prefer it, but I understand that there are reasons to not have it, and some people like those reasons enough. My issue is that we took something that can be compile-time checked in OOP (interfaces), replaced it with a feature that can be compile-time checked in FP (pattern matching), and somehow ended up with something that isn't compile-time checked. It seems like a waste to not be able to check this.
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
Become a patron and get access to source code and exclusive live streams: www.patreon.com/posts/visitor-design-81382001
That UnreachableException was a great bonus!
Thanks for your excellent content.
I'm glad to hear you liked it!
I always struggle to find a use case for this pattern. You opened my eyes!
Excellent example of simplifying code - thank you! One of the barriers to my adoption of type-based pattern matching goes back to the earliest years of C#, when I was advised to use reflection sparingly. Pattern matching, or in this case type-testing if you will, is a form of reflection. It is evident that C# reflection is much faster than in the old days.
Great video! I am waiting for other design patterns with practical use cases, especially those infrequently used.
This the same thing came to my mind when I've read why Accept method needs be added and do a double dispatch. Thanks for showing that here.
Top quality content as always! Love your Pluralsight courses! Thanks for sharing.
The visitor pattern helps processing complex tree structures. But yeah, that requires a tree structure first.
People in compiler programming use visitors to translate program code (syntax tree) into machine code. Or you can replace flawed domain models using such a translation technique via fluent api syntax trees as well. I think the visitor pattern is still a powerful pattern for trees.
I love it!! I didn't know that Visitor Design pattern was function pattern.
Well, in traditional visitor compiler won't capture "a new class" error because the domain class hierarchy is required. Compiler will generate a call to superclass Accept method. No compile time, no runtime error will occurr, heavy debugging time...
Very accessible way of explaining programming patterns! Imo even better than nick chapsas channel :) You have my sub sire!
Very nice video Zoran, good work!
Thanks!
Just found, nice tutorial. Got to see more your videos. Thanks
Many design patterns are way easier to implement with functional programming. Strategy is just a function with the specified signature (params and return). My only complain here is that languages like Rust would not need the _ => wildcard for the matching pattern, since implementing all subtypes is already exhaustive in my opinion.
Quite effective video! I like the "fluency" or how well the writing code is aligned with the talk. The first thing that comes to me is to check if there's some analyzer that can ensure exhaustive pattern matching at compile time, perhaps that is good fit for larger projects?
I think the compile time error is a pretty big difference. I don't' know as its worth all the complexity and boiler plate just to prove its well-formed, but it is a difference.
That difference is important in sensitive portions of code, like tree transformation visitors, library code, and similar. Take ExpressionVisitor in C# as a good example. It is virtually unimaginable that someone could transform expressions in .NET using any approach other than implementing the explicit visitor.
On the other hand, most business applications do not have that problem. You would model business concepts as they appear and then define mappings to other concepts for years. Practice shows that adding variants to a business concept happens so rarely that you can safely ignore the nuisance that comes with that. How hard can it be to augment mapping expressions for a domain type once in two years? That is how often that happens!
Of course, there are certain prerequisites to making it work that way. For one thing - discipline, discipline, discipline. Make every concept a small one. Build larger concepts by applying composition to smaller ones, not by deepening the hierarchies. Avoid hierarchies more than one level deep. Any hierarchy deeper than that must come with a rock-solid justification.
@@zoran-horvat Just pointing out to viewers that the OO version is solving a 'harder' problem, it isn't just verbose for the sake of it.
The real question is do you have this problem and even if you do, is it worth this price to solve? Probably not.
This approach saves on complexity in the implementation but requires a special tool/testing to ensure correctness before deployment.
It would be nice to be able to instruct the compiler that a type matching switch statement must be exhaustive over the derived types. Though it is probably not hard to write an analyzer for that.
Thank you so much for this video, was interesting to see VDP!
Visitor is by far the least frequently used pattern. But it is still irreplaceable in usages such as transforming expression trees and similar.
I think the main benefit for the visitor pattern is when you expect others to write their own visitors to walk your (sealed) composite structure. In LINQ there is an abstract ExpressionVisitor that you could use to translate the Expression to whatever you like, using whatever you want. You could ofcourse still opt for pattern matching instead when walking the Expression object but why would you if you could just have your class inherit from the abstract so you get all the different types in their own method with autocomplete from your IDE? This does seem like the sole reason for this pattern to stay around in C# however.
Amazing video. Thank you for sharing.
Great video and format!
Koji si ti kralj. Tako je lepo slusati te
Vežbalo se...
SwitchExpressionException is better suited for this scenario as it can also capture the value of unmatched case.
That is an interesting suggestion. I will consider it next time, though it has a drawback that it is telling out the implementation detail. But I see your point and I will give it some time of thinking.
I think the visitor pattern plays well with java sealed class hierarchies. It would be nice to have something like that in c# as well.
It's a powerful feature on its own allowing for example exhaustive enum like hierarchies similar to rusts enums.
For the "implicit visitor" in particular it allows for a exhaustive switch without an catch all and giving you an compile error once someone adds a class to the sealed hierarchy.
Between the traditional visitor and pattern matching approaches is there any significant performance difference? Is the pattern matching just compiler magic that is type checking under the hood (which you could do in older c# direct with “is” and cast) which is slower than a polymorphic call?
No, it converts to "as" construct with null checking for reference types. And these works faster than double virtual calls.
your content is awesome, pretty glad i found it :D
original visitor design pattern can leverage dependency injection? Given the functional pattern matching approach lacks of it that could mark a difference
You can inject dependencies into functions, too. The pattern matching expression can operate within a closure.
If we remove the "pattern matching" in the "implicit visitor" we'd have a "type checking" analysis into that method, Which would smell, and be a little confusing because besides, the proposed "implicit visitor" pattern looks more like the "factory method" pattern than the "visitor" pattern. That's my doubt.
Type matching expressions are the basis of working with discriminated unions in functional programming and discriminated unions are the basis of domain modeling.
It is interesting to note that the Visitor pattern is adding this technique to object-oriented languages, whereas that same technique is supported natively in any functional language. Therefore, the Visitor was introduced to overcome the native deficiency of OOP.
As C# gains more functional elements, pattern matching, including type matching, will gain more and more prominence.
Regarding code smell: it could turn into a code smell if target objects were mutable. In an immutable design, it is a mapping like any other.
Professor Horvat thank you very much for your explanation, it was very enriching.
One big thing you forgot to mention is that these are extension methods so its also possible to call them from the name itself. Name.CommonName()
What do you mean forgot? I made that an extension method.
@@zoran-horvatYou made them into extension methods, but you never mentioned it :)
Very similar to a catamorphism in F#
@zoran-horvat Thank you very much for the demonstration of the visitor pattern, excellent work keep them coming,
one question about the names, in most systems you get the names from a database or an API and then you map them to a single DTO like `Person` record but in your solution, you have 3 records `SimpleName`, `Mononym` and `CompoundName`. and for the pattern to work you need multiple DTOs to work
How would you resolve this problem if you want to implement the Visitor pattern?
For reference: th-cam.com/video/tq5ztZO45-g/w-d-xo.html
The thing you need to ask yourself is whether the receiving party of your API cares which type of name the person is using.
The visitor in this example is meant to return a string representation of the name object, regardless of its type. So your DTO, or receiving end would simply have a string property.
In this case traffic would be one way and you would need a different approach if you were to ever allow creating or updating of the names.
The Author API would probably care a lot about the types of names, but in the publications/books API you simply want to know the names.
You could also change the return type of your visitor, exploring a different pattern/approach altogether might in the end be better.
Thank you.
The idea of needing to know/remember to implement code somewhere else (along with nasty switch/if class type checking and exception throwing if it does not exist) once a new class implementation is added to the solution has always felt wrong to me. Its not something I personally would do with the only exception being if I was trying to extend existing classes which reside inside a third party library and even then I would probably do it a different way.
Here is the answer I have already posted on a similar question:
The problem of having or not having compile-time safety is important in sensitive portions of code, like tree transformation visitors, library code, and similar. Take ExpressionVisitor in C# as a good example. It is virtually unimaginable that someone could transform expressions in .NET using any approach other than implementing the explicit visitor.
On the other hand, most business applications do not have that problem. You would model business concepts as they appear and then define mappings to other concepts for years. Practice shows that adding variants to a business concept happens so rarely that you can safely ignore the nuisance that comes with that. How hard can it be to augment mapping expressions for a domain type once in two years? That is how often that happens!
Of course, there are certain prerequisites to making it work that way. For one thing - discipline, discipline, discipline. Make every concept a small one. Build larger concepts by applying composition to smaller ones, not by deepening the hierarchies. Avoid hierarchies more than one level deep. Any hierarchy deeper than that must come with a rock-solid justification.
@@zoran-horvat I agree that in reality adding another implementation may be infrequent or never happen but it still feels sloppy to me. I would say there is a case that the matching approach in the video breaks OCP but even I would say nothing is ever perfect and there could be times where breaking a SOLID rule(s) might be ok. Anyway, I'm really enjoying your videos - you're a very clever guy who deservers more subs/views.
The fact that this is not checked at compile-time creates an unnecessary cost, and a cost which is atypical for functional-style design. An unreachable exception is just a run-time crash for something you failed to check at compile-time, and should be considered a code smell. This seems to be a symptom of squeezing a functional pattern into an object-oriented context. A functional language would have PersonalName as a sum type, and so it could be checked at compile-time if all the summand types are handled in pattern matching. I'm not sure that this is impossible to check for the class hierarchy of OOP, but it's clear that C# at least isn't interested in doing that check.
Everything you said is right - to a point. By requesting compile-time safety, you are dismissing entire programming languages. C# is going this path for the last 15 years already and you can expect that all remaining deficiencies in its current state are temporal.
@@zoran-horvat I'm not trying to be a stickler about compile-time checking everything. I will always prefer it, but I understand that there are reasons to not have it, and some people like those reasons enough.
My issue is that we took something that can be compile-time checked in OOP (interfaces), replaced it with a feature that can be compile-time checked in FP (pattern matching), and somehow ended up with something that isn't compile-time checked. It seems like a waste to not be able to check this.
@@alxjones I see your point, and indeed the things will settle down once we get discriminated unions in C#.
And this is precisely why I still prefer to use the Visitor pattern explicitly. The compile-time checks are very compelling 😇