Las clases selladas: cerrar una jerarquía de forma deliberada

En Java 8, una jerarquía solo puede estar en dos estados: abierta o cerrada. Declaras una interfaz MoyenPaiement y cualquiera, en cualquier módulo, puede implementarla, incluso con invariantes que no habías previsto. O bien pones final en una clase y nadie puede derivar nada de ella. Entre ambos extremos, nada. Sin embargo, la mayoría de los modelos de negocio quieren justo el punto medio: un pago es una tarjeta, una transferencia o un cheque, esa lista está completa y no debe ser ampliada por un tercero.

El coste de esta carencia se paga en cada switch. Escribes una cascada de instanceof, terminas con un else { throw new IllegalStateException("type inconnu"); } y sabes que esa rama está muerta, salvo el día en que un compañero añade una cuarta implementación. El compilador no dice nada, porque ignora cuántas implementaciones hay. Descubres el olvido en producción, en forma de excepción. Una clase sellada traslada ese descubrimiento a la compilación: da al compilador la lista exhaustiva de subtipos y este se vuelve capaz de decirte qué caso has olvidado.