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.
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 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.
Год назад
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...
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.
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.
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?
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.
original visitor design pattern can leverage dependency injection? Given the functional pattern matching approach lacks of it that could mark a difference
@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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-tq5ztZO45-g.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 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.
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.
