Lista de Exercícios – POO em Java

Tópicos: Herança, Encapsulamento, Classe Abstrata e Sobrescrita de Métodos. 5 alternativas por questão (a–e); a e) é sempre NDA.

1) Herança

(Teórico)

Sobre herança em Java, assinale a correta.

a) Uma classe pode herdar de múltiplas superclasses diretamente. b) A palavra-chave `extends` é usada para herdar de uma interface. c) Herança implementa “é-um” e favorece reuso de código. d) Construtores são herdados automaticamente. e) NDA

(Prático – leitura de código)

Dado:

class A { int x = 1; }
class B extends A { int x = 2; int f(){ return super.x; } }

`new B().f()` retorna:

(Teórico)

Qual afirmação é **verdadeira**?

a) `final class` pode ser estendida se o construtor for público. b) Métodos `private` podem ser sobrepostos (override). c) Atributos não são *override*, apenas *shadow/hide*. d) Toda classe herda de alguma interface implícita. e) NDA

(Prático – completar conceito)

Para impedir que uma classe seja estendida, use:

(Teórico)

Sobre construtores em herança:

a) O construtor da subclasse chama implicitamente `super()` se nada for declarado. b) `super()` só pode aparecer após qualquer outra instrução. c) Construtores são herdados como métodos comuns. d) `this()` e `super()` podem aparecer na mesma linha. e) NDA

(Prático – seleção de termo)

Complete:

class Animal { void som(){} }
class Cachorro ____ Animal { }

(Prático – sobrescrita x ocultação)

Dado:

class P { static void f(){} }
class C extends P { static void f(){} }

O que ocorre?

a) Sobrescrita válida de método estático. b) Ocultação (*hiding*) de método estático. c) Erro de compilação. d) *Override* dinâmico em tempo de execução. e) NDA

(Teórico)

Se `B extends A`, então:

(Prático – seleção de termo)

Complete:

public class Veiculo {
  protected int velocidade;
}
public class Carro _____ Veiculo { }

2) Encapsulamento

(Teórico)

Encapsulamento busca:

a) Expor todos os campos para facilitar acesso. b) Ocultar detalhes internos e expor uma interface estável. c) Impedir herança. d) Eliminar necessidade de testes. e) NDA

Resposta correta: b

Por que correta: Esconde implementação, expõe contrato.

Por que as outras não: a/c/d) não definem encapsulamento.

(Prático – seleção de modificador)

Melhor modificador para campo sensível:

class Conta { ____ double saldo; }

Resposta correta: b

Por que correta: Restringe acesso, forçando métodos de acesso.

Por que as outras não: a/c/d) expõem demais.

(Prático – getters/setters)

Para manter invariantes, usamos:

Resposta correta: b

Por que correta: Permite validação.

Por que as outras não: a/c/d) não resolvem encapsulamento.

(Teórico)

`private` significa:

a) Visível em qualquer classe do pacote. b) Visível em subclasses apenas. c) Visível somente na própria classe. d) Igual a `final`. e) NDA

Resposta correta: c

Por que correta: Escopo restrito à classe.

Por que as outras não: a/b/d) incorretas.

(Prático – completar assinatura)

Complete um getter padrão:

class Pessoa { private String nome; public String ____(){ return nome; } }

Resposta correta: a

Por que correta: Convenção JavaBeans.

Por que as outras não: b) setter; c/d) nomes incorretos.

(Prático – seleção de termo)

Para restringir escrita externa no campo `saldo`:

a) `public double saldo;` b) `private double saldo;` e métodos `depositar/sacar` c) `protected double saldo;` d) `double saldo;` (pacote) e) NDA

Resposta correta: b

Por que correta: Controla via métodos.

Por que as outras não: a/c/d) permitem acesso indevido.

(Teórico)

`protected` garante:

a) Acesso somente dentro da classe. b) Acesso no pacote e em subclasses (mesmo fora do pacote). c) Acesso global. d) Igual a `private`. e) NDA

Resposta correta: b

Por que correta: Regra de visibilidade do `protected`.

Por que as outras não: a/c/d) incorretas.

3) Classe Abstrata

(Teórico)

Uma classe abstrata:

a) Pode ser instanciada diretamente. b) Pode conter métodos concretos e abstratos. c) Deve ter todos os métodos abstratos. d) É igual a interface. e) NDA

Resposta correta: b

Por que correta: Pode misturar concretos e abstratos.

Por que as outras não: a) não pode instanciar; c) não é obrigatório; d) não é igual.

(Prático – assinatura)

Escolha a definição correta:

a) `abstract class C { abstract void m(){} }` b) `abstract class C { abstract void m(); }` c) `class C { abstract void m(); }` d) `interface C { abstract void m(){} }` e) NDA

Resposta correta: b

Por que correta: Método abstrato sem corpo.

Por que as outras não: a/d) corpo não permitido; c) classe não abstrata com método abstrato.

(Teórico)

Sobre construtores em classes abstratas:

a) Não podem existir. b) Existem e podem ser chamados por subclasses. c) São herdados como métodos. d) São sempre `private`. e) NDA

Resposta correta: b

Por que correta: Construtor existe para inicialização ao estender.

Por que as outras não: a/c/d) incorretas.

(Prático – modelagem)

Quando escolher classe abstrata em vez de interface?

a) Quando precisa fornecer estado e comportamento parcial comum. b) Quando só precisa de contrato sem implementação. c) Quando quer herança múltipla de implementação. d) Quando precisa de *records*. e) NDA

Resposta correta: a

Por que correta: Abstrata permite estado/implementação parcial.

Por que as outras não: b) é caso de interface; c) Java não tem; d) irrelevante.

(Prático – completar código)

Complete:

abstract class Forma {
  abstract double area();
}
class Circulo extends Forma {
  ____ double area(){ return Math.PI * r * r; }
  double r;
}

Resposta correta: c

Por que correta: Implementa método abstrato com visibilidade compatível; `public` é comum para API.

Por que as outras não: a) não pode manter abstrato; b/d) sem sentido aqui.

(Teórico)

Declarações válidas:

a) `abstract final class X {}` b) `abstract class X {}` c) `final abstract class X {}` d) `abstract class X extends final Y {}` e) NDA

Resposta correta: b

Por que correta: Classe abstrata simples é válida.

Por que as outras não: `abstract` e `final` são incompatíveis; não se pode estender classe `final`.

(Teórico)

Em classes abstratas:

a) Todos os métodos devem ser `final`. b) Métodos abstratos não podem ser `private`. c) Campos obrigatoriamente `public`. d) Não pode ter métodos `static`. e) NDA

Resposta correta: b

Por que correta: `private` impediria implementação na subclasse.

Por que as outras não: a/c/d) falsas.

(Prático – leitura de código)

abstract class A { abstract int x(); }
class B extends A { int x(){ return 42; } }

`new B().x()` retorna:

4) Sobrescrita de Métodos (Override)

(Teórico)

Override correto requer:

a) Mesma assinatura e mesmo modificador exato. b) Mesma assinatura e compatibilidade de visibilidade (não reduzir), além de anotações opcionais. c) Nome igual, parâmetros diferentes. d) Retorno sempre idêntico, sem covariância. e) NDA

(Prático – @Override)

O uso de `@Override` ajuda a:

a) Evitar herança. b) Forçar `final`. c) Detectar erros de assinatura em tempo de compilação. d) Transformar estático em dinâmico. e) NDA

(Prático – selecionar termo)

Complete o override:

class A { Number f(){ return 1; } }
class B extends A {
  ____ Integer f(){ return 2; }
}

(Teórico)

Não é possível sobrescrever:

(Prático – leitura de código)

class P { String m(){ return "P"; } }
class C extends P { @Override String m(){ return "C"; } }
System.out.println(new P().m() + new C().m());

Saída:

(Teórico)

Sobre anotações:

a) `@Override` é obrigatória para compilar. b) `@Override` é opcional mas recomendada. c) `@Override` só vale em interfaces. d) `@Override` muda o *dispatch* dinâmico. e) NDA

(Prático – seleção de termo)

Para chamar a versão da superclasse dentro do override:

@Override
void m(){ /* … */ }