The "Sealed classes" feature, as described here, just feels all wrong to me.<p>They are saying that if you have a (normal) interface, anyone can create a new class implementing it. So if you do<p><pre><code> if (x instanceof Foo) {
...
} else if (x instanceof Bar) {
...
} ...
</code></pre>
then your code will break at runtime if someone adds a new class, as that code won't expect it. So the article is saying the solution is to use the new "sealed" interfaces feature, so nobody can create any new classes implementing that interface, and your "if" statement will not break.<p>Surely object-oriented programming already thought about that and already solved that? (I know object-oriented programming is out of vogue at the moment, but Java <i>is</i> an object-oriented language.)<p>The solution there is to add a method to the interface, and all your classes implement that. Then rather than having a massive if/switch statement with all the options, you call the method.<p>That is better than preventing people from extending your code, it <i>allows</i> them to extend your code. They just have to implement the method. And the compiler will force them to do that, so they can't even accidentally forget.<p>The example given of color spaces (RGB, CMYK etc.) is a great example. I can absolutely imagine writing code which uses color spaces, but then some user or client having a need to use a weird obscure color space I haven't thought of. I wouldn't want to restrict my code to saying "these are the color spaces I support, due to this massive if/switch statement listing them all, the code is written in such a way that you can't extend it".