Implementando uma Interface

Conforme orientação eu criei a interface Imprimível:

public interface Imprimivel {
    void imprimir();
}

Mas diferente da solução proposta eu usei o protected e não os getters e setters:

public class Relatorio implements Imprimivel{
    protected String Titulo;
    protected String Conteudo;

    public Relatorio (String Titulo, String Conteudo){
        this.Titulo = Titulo;
        this.Conteudo = Conteudo;
    }

    @Override
    public void imprimir(){
        System.out.printf("\nTítulo:  %s", Titulo);
        System.out.printf("\nConteúdo:  %s", Conteudo);
    }
}

Instanciei e funcionou:
public class Main {
    public static void main(String[] args) {
        Relatorio rel = new Relatorio(
                "Relatório 2025", "Tudo funcionando conforme esperado.");

        rel.imprimir();
    }
}

Minha dúvida é: ainda não está claro para mim quando eu devo usar os getters and setters e quando eu devo usar o proteced.

Oii, João! Tudo bem?

Parabéns por ter implementado o código e testado. E fique tranquilo, essa dúvida é muito comum e fundamental para entender a orientação a objetos de verdade.

O Resumo da ópera:

private + Getters/Setters: É o padrão de ouro (default). Use quase sempre. Garante encapsulamento (proteção e controle do dado).
protected: Use apenas quando você tem certeza que classes filhas (herança) precisam mexer diretamente naquela variável sem passar por validações.

Por que o Instrutor usou private e Getters/Setters?

Imagine que, no futuro, a regra de negócio mude: "O título do relatório não pode ser vazio ou nulo".

1. Usando protected (acesso direto):
Como a variável está exposta (para o pacote e herdeiros), qualquer outra classe pode fazer isso:

rel.Titulo = ""; // Deixou vazio e quebrou a regra!

Você não tem como impedir isso, pois o acesso é direto à variável.

2. Usando private + Setter (acesso controlado):
A variável está trancada. Só entra quem passar pelo método set. Aí você ganha controle:

public void setTitulo(String titulo) {
    if (titulo != null && !titulo.isEmpty()) {
        this.titulo = titulo;
    } else {
        System.out.println("Erro: Título inválido!");
    }
}

Se alguém tentar rel.setTitulo(""), o seu código protege o dado. Esse é o poder do encapsulamento.

E o protected?

O protected é o "meio termo". Ele diz: "Essa variável é privada para o mundo externo, mas visível para minhas classes filhas (herança) e classes do mesmo pacote".

Costumamos usar protected quando queremos facilitar a vida das subclasses pra que elas não precisem ficar chamando getIsso() ou setAquilo() o tempo todo, mas isso gera um acoplamento forte. Se você mudar o nome da variável na classe mãe, quebra o código das filhas que a usam diretamente.

Na dúvida, comece sempre com private. Se, e somente se, você perceber que uma classe filha realmente precisa de acesso direto, você muda para protected.

Um detalhe importante no seu código (Boas práticas):

Notei um pequeno detalhe de convenção de nomes no Java.

Classes: Começam com Maiúscula (ex: Relatorio).
Atributos/Variáveis: Começam com minúscula (camelCase).

No seu código você usou String Titulo. O ideal, para seguir o padrão de mercado, seria String titulo.

Como ficaria sua classe refinada:

public class Relatorio implements Imprimivel {
    // 1. Atributos privados (segurança) e em minúsculo (convenção)
    private String titulo;
    private String conteudo;

    public Relatorio(String titulo, String conteudo) {
        this.titulo = titulo;
        this.conteudo = conteudo;
    }

    // 2. Getters e Setters (para permitir leitura/escrita controlada se necessário)
    public String getTitulo() {
        return titulo;
    }

    // Exemplo de Setter: só permite alterar se não for vazio
    public void setTitulo(String titulo) {
        this.titulo = titulo;
    }
    
    // ... getters e setters do conteudo ...

    @Override
    public void imprimir() {
        // Aqui dentro da própria classe, você acessa direto
        System.out.printf("\nTítulo: %s", this.titulo);
        System.out.printf("\nConteúdo: %s", this.conteudo);
    }
}

Ficou mais claro a diferença de proteção entre eles? Você está mandando super bem nos testes! Continue assim.

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Trilhas por carreira

Carreiras de IA

Carreiras de Dados

Carreiras de Cyber

Carreiras de DevOps & Cloud

Carreiras de UX & UI

Carreiras de Mobile & Front-End

Carreiras de Back-End

Carreiras de Negócios

Cursos universitários FIAP

Tópicos relacionados

Conteúdos Alura com o tema