Classes seladas: fechando uma hierarquia de forma intencional

No Java 8, uma hierarquia só tem dois estados possíveis: aberta ou fechada. Você declara uma interface MoyenPaiement e qualquer pessoa, em qualquer módulo, pode implementá-la — inclusive com invariantes que você não havia previsto. Ou então você coloca final em uma classe, e ninguém mais pode derivar nada dela. Entre os dois extremos, nada. No entanto, a maioria dos modelos de negócio quer exatamente o meio-termo: um pagamento é um cartão, uma transferência ou um cheque, essa lista está completa e não deve ser ampliada por um terceiro.

O custo dessa ausência é pago a cada switch. Você escreve uma cascata de instanceof, termina com um else { throw new IllegalStateException("type inconnu"); } e sabe que esse ramo está morto — até o dia em que um colega adiciona uma quarta implementação. O compilador não diz nada, porque ele não sabe quantas implementações existem. Você descobre o esquecimento em produção, na forma de uma exceção. Uma classe selada transfere essa descoberta para a compilação: ela fornece ao compilador a lista exaustiva dos subtipos, e ele passa a ser capaz de dizer qual caso você esqueceu.