The solution with sealed classes also allows anyone to extend the code, but in a different dimension than the solution with an interface method.
The solution with interface method and virtual call is very inflexible when you want to add new operations instead of adding new classes. If you want to just add one new operation, then you have to go to all the implementations and add new methods. And you possibly break the implementations you don't have access to. And all those methods must be defined in a single class, even if they are unrelated to each other. This seriously degrades code readability (and performance as well - those vcalls are not free either).
The sealed class extends much better in this case. You just add a new switch in one place and done. No breaking of backwards compatibility.
> If you want to just add one new operation, then you have to go to all the implementations and add new methods.
not necessarily, if you have extension methods (kotlin, swift) you have the option to extend the interface and only override the specific implementation when needed
The solution with interface method and virtual call is very inflexible when you want to add new operations instead of adding new classes. If you want to just add one new operation, then you have to go to all the implementations and add new methods. And you possibly break the implementations you don't have access to. And all those methods must be defined in a single class, even if they are unrelated to each other. This seriously degrades code readability (and performance as well - those vcalls are not free either).
The sealed class extends much better in this case. You just add a new switch in one place and done. No breaking of backwards compatibility.
This is the famous expression problem.
https://pkolaczk.github.io/in-defense-of-switch/