2
respostas

Uso do protected x super.getSalario

Fala galera, beleza?

Caras, eu entendi sobre usar o protected para visibilidade entre mãe e filha. Ou utilizar private na class, mas realizar o acessando através de;

"Exemplo: super.getSalario();"

Mas como estou inciando os estudos gostaria de saber especificamente onde utilizar o protected, já que ele existe na linguagem, ou se devo sempre utilizar private e reutilizar o que preciso através de; super.get como mostrado a cima.

Ficou fácil o entendimento sobre minha duvida?

2 respostas

Boa noite Thiago, tudo tranquilo?

Essa pergunta de quando utilizar um e outro no âmbito de acesso a variável assola muita gente por ai e a resposta mais correta e que sempre deixa o pessoal com mais dúvida ainda é: DEPENDE. Mas ai você pode perguntar, depende do que? Depende de quem pode acessar aquele método ou atributo. Vamos para um exemplo prático para elucidar um pouco as coisas.

package br.com.alura.test;

public class Conta {

    private int numero;
    private double saldo;

    protected void saca(double valor)  {
        this.saldo = valor + this.saldo;
    }

    public void transfere(double valor, double taxa, Conta contaDestino)
    {
        if(this.saldo < valor + taxa) {
            System.out.println("Saldo insuficiênte");
        } else {
            this.saldo = this.saldo - valor - taxa;
            contaDestino.saldo = this.saldo + valor;
        }
    }
}

Perceba o seguinte, eu coloquei os atributos como private, ou seja, somente dentro da classe conta você terá acesso a eles diretamente utilizando this.saldo ou saldo. Isso trará segurança ao seu código. Com certeza você já deve ter ouvido falar sobre essa tal de segurança que o controle de acesso traz. A partir disto o que talvez você pergunte é: Segurança contra o que? A resposta está mais perto de você do que imagina. A segurança é contra você mesmo e contra programadores desavisados.

Por exemplo, temos o método transfere que transfere o saldo de uma conta para outra e com isso é cobrado uma taxa. Imagina agora sua variável public double saldo e um programador desavisado que quer fazer uma transferência e faz o seguinte:

contaOrigem.saldo = contaOrigem.saldo - valor

e

contaDestino.saldo = contaDestino.saldo + valor

Temos um problema, pois o programador não sabia que tinha que cobrar uma taxa por transferência e o controle de acesso não barrou ele, então o mesmo achou que estava fazendo certo em acessar direto a variável do objeto e sair modificando como ele entendesse. Isso também seria possível se a variável fosse protected double saldo e um programador desavisado que está dentro do mesmo pacote realizasse essa operação ou até mesmo em uma subclasse.

Essa segurança fornecida pelo modificadores de controle de acesso são ótimos pois caso a variável saldo fosse private o programador desavisado seria então avisado por sua IDE ou pelo compilador que ele tentou fazer algo que não está certo. Mas é claro, você não pode declarar todo o seu código como private, você tem que ponderar o que deve ou não ser de acesso a outros locais. Com isso talvez o DEPENDE agora ficou mais claro.

Então a dica que eu posso lhe dar agora seja a seguinte: Comece com private, caso mais alguma classe precise do recurso suba um nível, vá para o protected (ele é um meio termo entre o public e o private). Ainda precisa de mais acesso?! Vá para public. Mas sempre tenha em mente antes de subir o controle de acesso o que um programador desavisado pode fazer com o recurso que você acabou de dar a ele.

Com grande acessos, vêm grandes responsabilidades.

Mais informações sobre controle de acesso: https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

Caro Gabriel,

Realmente no começo da leitura achei que seria complicado de entender a ideia já que estou iniciando os estudos. rs

Mas ao final percebi o como, quando e onde usar. Acho que agora é mais uma questão de tempo para começar a ter uma percepção maior sobre o uso.

Muito obrigado!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software