Questão de Programação — Programação Orientada a Objetos — FGV 2025

Classes sealed, final e non-sealed em Java

Gabarito: letra C. O erro está na classe MPM: sendo declarada sealed, ela é obrigada a listar explicitamente suas subclasses permitidas na cláusula permits — e, se não o faz, o código não compila. As demais alternativas descrevem situações que, na verdade, são válidas em Java (JLS 8.1.1.2 e 8.1.1.3).

O mecanismo de classes seladas (sealed) foi introduzido no Java 17 (JEP 409) para permitir que uma classe ou interface restrinja quais outras classes podem estendê-la ou implementá-la. Quando uma classe é declarada como sealed, ela deve declarar, na cláusula permits, todas as subclasses diretas permitidas. Essas subclasses, por sua vez, devem ser declaradas como final, sealed ou non-sealed. A regra é rígida: se uma classe sealed não lista nenhuma subclasse em permits, o compilador acusa erro — é exatamente o que ocorre com a classe MPM no código da questão.

Para entender por que as outras alternativas estão erradas, é preciso dominar as três palavras-chave que controlam a herança em Java:

• final: a classe não pode ser estendida por ninguém. É o modificador mais restritivo.

• sealed: a classe pode ser estendida, mas somente pelas subclasses listadas na cláusula permits.

• non-sealed: a classe pode ser estendida por qualquer outra classe, sem restrição — é o comportamento "normal" de herança, mas declarado explicitamente para "abrir" uma hierarquia que estava selada.

A hierarquia do Ministério Público da União (MPU) é usada apenas como nome de classes para ilustrar o conceito — não há relação com a legislação do MPU em si. A questão é puramente de sintaxe e semântica da linguagem Java.

Vamos analisar cada alternativa com base nessas regras.

Alternativa A — ❌ Incorreta

Afirma que a classe MPU, sendo sealed, omitiu a cláusula permits. Isso não é um erro em si: uma classe sealed pode ser declarada sem permits se as subclasses permitidas estiverem no mesmo arquivo-fonte. Nesse caso, o compilador as infere automaticamente. Como as classes MPF, MPM, MPT e MPDFT estão no mesmo arquivo (o que a figura sugere), a omissão de permits na MPU é perfeitamente válida. O erro real está na classe MPM, que é sealed e não declara permits nem tem subclasses no mesmo arquivo.

Alternativa B — ❌ Incorreta

Diz que MPF, sendo final, não pode estender MPU, que é sealed. Isso é falso: uma classe final pode, sim, estender uma classe sealed, desde que esteja listada na cláusula permits da superclasse (ou seja inferida por estar no mesmo arquivo). Na verdade, final é uma das três formas válidas de uma subclasse de uma classe sealed se comportar. Não há conflito entre final e sealed nesse sentido.

Alternativa C — ✅ Correta ⟵ GABARITO

A classe MPM é declarada como sealed, mas não define nenhuma subclasse permitida — nem via cláusula permits, nem por ter subclasses no mesmo arquivo. Isso viola a regra do JLS: toda classe sealed deve ter pelo menos uma subclasse permitida. Sem isso, o código não compila. É exatamente o erro apontado no enunciado.

Alternativa D — ❌ Incorreta

Afirma que MPT, sendo non-sealed, não pode estender MPU, que é sealed. Isso é falso: non-sealed é justamente uma das três formas válidas de uma subclasse de uma classe sealed se comportar. Uma classe non-sealed pode perfeitamente estender uma classe sealed, desde que esteja na lista permits (ou seja inferida). O modificador non-sealed "abre" a hierarquia para que outras classes possam estender MPT.

Alternativa E — ❌ Incorreta

Diz que MPDFT, sendo final, não pode ser declarada após a classe MPM, de escopo protected. Isso é um absurdo sintático: a ordem de declaração das classes em um arquivo Java não tem nenhuma relação com modificadores como final ou protected. Além disso, protected não é um modificador válido para classes de nível superior (top-level) em Java — apenas para membros de classe. A alternativa mistura conceitos sem fundamento.

Gabarito: letra C