Private x Protected [Hierarquia]

Eu geralmente uso protected…

Mas mais por uma questão de gosto mesmo…

Aliás… geralmente eu deixo default (fica mais limpo o código… hehe)

Mas rola uma certa forçaçao de barra nessas boas praticas as vezes… O cara quer fazer tão certinho… que o programa fica cheio de coisas desnecessárias (to falando de maneira geral … nao só nesse caso)

Nunca vi um problema de ter um atributo protected e acessar ele diretamente da subclasse…

Mas já vi atributos private sem getter e setter… aí foi osso…

Das vezes que vi alguém colocando código no getter e no setter além do padrão… foi gambiarra… heheheh

Eu uso private e gets e sets protected. Se não precisa ser public, não será public.

Não existe perda de performance em usar gets e sets. A virtual machine é capaz de fazer inlining dos métodos.

traduzindo??

eu sempre uso private!! nunca uso protected!

ViniGodoy:

Eu uso private e gets e sets protected. Se não precisa ser public, não será public.

Não existe perda de performance em usar gets e sets. A virtual machine é capaz de fazer inlining dos métodos.

Digo o mesmo. :roll:

Na verdade, só acho protected necessário quando o método deveria ser private, mas pode haver necessidade de alguma sbuclasse sobrescrevê-lo (e ele não pode ser público, muito menos default).

Já campos, pelo menos no tempo que trabalho com Java nunca tive necessidade alguma de tê-los com visibilidade protected (apesar de várias classes do Java o utilizarem).

A questão é bastante simples é resume-se a aplicar a pedra fundamental da POO: separar claramente implementação de interface. Assim, os atributos de uma classe somente devem ser public se o get/set fazer parte da interface, ou seja, se o atributo representa uma propriedade no contrato de operação do objeto. Para fazer essa separação devemos usar interfaces, composição e delegação, que à primeira vista parece mais difícil que herança. Mas não o é. Isso porque quando projetamos uma classe para ser herdada devemos projetar duas interfaces: uma para quem usa e outra para quem estende. Resumindo:

public - interface para quem USA a classe

protected - interface para ESTENDE a classe

private - implementação

Assim, fica bem mais simples decidir se um membro deve ser private ou protected: se ele diz respeito à implementação da classe ele deve ser private, se ele deve ser exposto como parte do contrato entre a superclasse e a subclasse então ele deve ser protected.

aeciovc:

traduzindo??

Inline é a capacidade que o compilador tem de eliminar completamente uma chamada de um método, quando ele vê quei isso é possível.

Veja, sem inline uma instrução como:

public class Y {
    int value;

    public int getValue() { return value; }
}

int x = y.getValue();

faria:

1. Guardaria o valor do ponteiro de código na pilha;
2. Obteria o endereço de getValue();
3. Entraria no getValue() e obteria o valor de value;
4. Desempilharia o endereço do método antigo e mudaria o código para lá.
5. Atribuiria o valor de y para x.

int x = y.getValue();

int x = y.value;

Ou seja, a chamada de método não é feita e o atributo é diretamente obtido, como se fosse público.

public class A {
    private B b = new B();

    public void fazAlgo() {
          b.fazAlgo();
    }
}

public class B {
    private C c = new C();

    public void fazAlgo() {
          c.fazAlgo();
    }
}

public class C {

    public void fazAlgo() {
          //Faz qualquer coisa.
    }
}

Uma chamada a A.do() será substituida pelo compilado a uma chamada à c.Do(), direta, sem a necessidade de alocar pilha nos passos intermediários.

deu uma aula Vini! não conhecia isso!! vlw!

[size=9]Aécio Costa
Desenvolvedor Delphi e Java
Twitter: http://twitter.com/aeciovc[/size]

Dá uma lida:
http://www.compileroptimizations.com