Olá pessoal,
Estou lendo sobre encapsulamento e tá dando nó rsrsrs.
Eu tenho 4 classes que são implementações concretas de uma abstração. Lendo a apostila da Caelum, vi que é melhor preferir composição à herança, só que os métodos mudam muito pouco entre uma classe e outra. Criei então uma classe abstrata, porém com alguns métodos concretos, e fiz as filhas herdarem o que há em comum (e os métodos das filhas que reescrevem os da pai invocam os metodos da classe pai). Queria todos os atributos private, mas daí as classes filhas não herdariam os atributos. O que tiver protected na classe pai será acessível às outras classes do pacote que não forem filhas?? Pois se é assim não vejo utilidade para o protected.
cara vamos la
atributos private pertencem a classe.
class A {
private int i = 1;
public int getI(){ return this.i ; }
}
class B extends A {
private int i = 2;
public int getIdeUmJeitoDiferente(){ return this.i ; }
}
// considere este codigo
B b = new B();
System.out.println("b.getI=" + b.getI() + ", b.getIdeUmJeitoDiferente=" + b.getIdeUmJeitoDiferente());
o que vc vai imprimir? veja vc mesmo: http://ideone.com/ASNekj
vc precisa desenhar bem a suas classes pq não necessariamente vc consegue acessar os atributos, mas com certeza vc acessa metodos e o polimorfismo ajuda.
ao inves de pensar nos atributos, talvez vc queira metodos de acesso com uma determinada visibilidade. pense nisso.
Sobre o uso de herança, saiba que ela só faz sentido quando você quer dizer que determinada classe É de determinado tipo, utilizar herança somente para “enxergar” métodos da superclasse é um equívoco, neste caso, o correto seria você ter uma instância da classe da qual deseja acessar os métodos.
Sobre o protected, relaxa que é uma dúvida bastante comum até.
Em java temos 4 modificadores de visibilidade: public, protected, default e private.
Antes que questione sobre o default (que também é chamado de friendly por alguns autores) ele é implícito quando o membro da classe não for public, protected nem private.
Esses modificadores diferenciam o escopo de visibilidade dos membros da classe, conforme o quadro abaixo:
+-----------+---------+-----------+--------+--------+
| | global | subclasse | pacote | classe |
+-----------+---------+-----------+--------+--------+
| private | | | | X |
+-----------+---------+-----------+--------+--------+
| default | | | X | X |
+-----------+---------+-----------+--------+--------+
| protected | | X | X | X |
+-----------+---------+-----------+--------+--------+
| public | X | X | X | X |
+-----------+---------+-----------+--------+--------+
Explicando o quadro acima:
private só é acessível dentro da classe que declara.
default é acessível para a classe que declara e outras classes ou subclasses dentro do mesmo pacote.
protected é acessível para a classe que declara, para outras classes ou subclasses dentro do mesmo pacote e subclasses em pacotes diferentes.
public é acessível para todas as classes, subclasses, no mesmo pacote ou em pacotes diferentes.
Ou seja, não tem nenhum modificador de visibilidade em que o escopo de visibilidade seja apenas a classe e as subclasses, correto? Confesso que não gostei disso no Java… Mas, enfim, paciência.
Isso mesmo.
Neste caso, terias que utilizar o protected (ou default se as subclasses pertencem ao mesmo pacote da classe base).
Você comentou que não gostou disso, terias como explicar em que situação você vê um problema nisso?
Curiosidade minha mesmo. 
Bem, eu costumava ver herança como um aproveitamento de código. Eu tinha uma classe abstrata e ia derivar 4 classes filhas destas, aproveitando alguns pedaços de código (o que eu chamo de “métodos parciais”). Tipo:
abstract class ClassePai {
protected int atributo;
protected void metodo {
//faz alguma coisa
}
}
class ClasseFilha1 extends ClassePai {
void metodo {
//faz alguma coisa
super.metodo
//faz outra coisa
}
}
Se o protected fosse herdado como private para a classe filha, ou seja, se a classe filha tivesse acesso aos atributos e métodos da classe pai sem abrir visibilidade para outras classes do pacote, eu poderia usar a herança. Mas como não posso fazer isso sem quebrar o encapsulamento, vou ter que repetir muito código, pois são 4 classes que possum muitos pedaços de código parecidos.
Eu andei lendo a apostila da Caelum, e eles não recomendam herança justamente para não quebrar encapsulamento. Nem é uma herança forçada taxonomicamente falando, as classes no fundo são a mesma coisa, só com comportamentos ligeiramente diferentes, e eu ia aproveitar a classe pai para colocar tudo o que tivesse em comum entre elas (atributos e “métodos parciais”).
Enfim, já mudei de ideia rsrsrs
Não sei identar o código nesse forum rsrsrs
Essa é fácil de responder: [code]
// código aqui
[/code]
1 curtida
ahhh, eu tava usando < code >
1 curtida
