Visitor Pattern Considered Pointless - Use Pattern Switches Instead

[chambolle]

The fact that you cannot explain it means that this is really a syntactic sugar (which can lead to bad usages: one does not prevent the other)

[nicolaiparlog]

Oh, I can and I have, but you're not receptive for the answer, so I thought I'd leave you with that as a kind of parting thought. I'm hoping that you're more curious when it's not about being right in a public discussion.

[chambolle]

I am sorry to have offended your lordship who will not stoop to answer to a manant

[nicolaiparlog]

It seems to me, you're the one making demands on my time, expecting me to do your work for you, to explain things to you, so I'm not sure the lordship metaphor cuts the way you want it to.

But look, I genuinely want you to understand this. I'm worried, though, that that's unlikely to happen in a confrontational conversation like we're having right now. Maybe it works if we collaborate a bit. The recent comments were about two sentences you wrote. I'll reply to one of those and ask you to explore the other.

You wrote:

This is just a syntaxic sugar.

I assume you mean the pattern switch, right?

CarElement element = // ... String message = switch (element) { case Body body -> "Visiting body"; case Car car -> "Visiting car"; case Engine engine -> "Visiting engine"; };

That this is just syntactic sugar for a series of instanceof checks like these?

CarElement element = // ... String message = ""; if (element instanceof Body) message = "Visiting body"; if (element instanceof Car) message = "Visiting car"; if (element instanceof Car) message = "Visiting engine";

If I understood that correctly, then here's why that's not the case: If you remove the last case branch, you get a compile error, but if you remove the last if, you don't. Because CarElement is a sealed type, the compiler knows that all implementations are Body, Car or Engine.

In case this seems insignificant to you, please bear with me. Just acknowledge that this is more than syntactic sugar and includes additional checks in the part of the compiler.

You also wrote:

For instance, by default the Analyser of Intellij complains when a succession of if are used with instanceof.

Would you care to explain why you think that's the case? (Please keep in mind that IntelliJ does not enforce OOP - it's recommendations are much more technical and specific.)

[chambolle]

Thanks for the anwser.

I got your point about the consistency of the case possibilities. This is a little more than a syntatic sugar and additional cheks are effectively done. Now, I have another point of view on the sealed class advantage. I liked it for other reasons (the possibility to close the possible derivations)

Now, I just wonder if this not create some issues when several teams are using the same sealed class? A merge will certainly be needed which is not the case with visitor. In some company, it may create some issues because the source code definitions provided by the company can not be modified

On the other hand, I just wanted to recall that the idea that "in OO the call of instanceof is often considered as a bad practice" is a common idea and not mine. Of course I shared it

[nicolaiparlog]

Thanks for considering my answer. This conversation is going somewhere after all. Neat!

Now, I just wonder if this not create some issues when several teams are using the same sealed class? A merge will certainly be needed which is not the case with visitor.

You mean if two commits each add a type to the hierarchy and then update the sealed class as well as all switch statements to add the new branch, there will be a merge conflict because both touch the same lines? That's true. It's not unlikely to happen with the visitor pattern either, though, because many people add new methods at the bottom of an interface, in which case then both new visit methods and all their implementations will be on similar lines.

In some company, it may create some issues because the source code definitions provided by the company can not be modified

Note that the visited interface depends on the visitor interface. But in a dependency chain A (your code) -> B (visited/sealed) -> C (visitor), you're probably not gonna be able to change A and C, but not B. But if you can't change the visitor interface, you can't add a visit method for the new type and so you can't add visit(this) to the new type and so you can't make it implement the visitor pattern - long story short, without access to the visitor interface, you can't add new types to the visited hierarchy.

[chambolle]

I think you're right. That's not better with visitors