Boa noite, após baixar vários PDFs, manuais e apostilas tenho dúvida ainda em alguns termos;
diferença entre variável de instância e de referência
diferença entre implements e extends
diferença entre classes e interfaces
diferença entre getters e setters
alguém poderia ajudar?
Meu camarada!
Já tive estas dúvidas, só que agora não posso responde-las, mas amanhã pela manhã lhe responderei.
Vá dormir agora, pois é isso que estarei fazendo.
Boa noite.
Vamos lá, erick.
Muita calma nessa hora… tudo vai dar certo…
A variável de instância é declarada em uma classe, mas fora de qualquer método daquela classe. Já uma variável de referência é utilizada para referenciar um objeto.
Ex.:
[code]class Exemplo{
String nome; //variável de instância nome
int idade; //variável de instância idade
Pessoa p = new Pessoa(); //Aqui é criado um objeto e a variável p referencia esse objeto
//A variável p é chamada variável de referência
public void metodoExemplo(){
//código
}
//outros métodos
}[/code]
O extends é utilizado quando para classes e implements para interfaces. Você só pode extender uma classe, mas pode implementar várias interfaces.
Ex.:
class Exemplo extends ExemploPai{ //ExemploPai é uma classe
//Corpo da classe
}
class Exemplo implements ExemploInterface{//ExemploInterface é uma interface
//Corpo da classe
}
class Exemplo extends ExemploPai implements Exemplo1, Exemplo2{//ExemploPai é uma classe
//Exemplo1 e Exemplo2 são interfaces
//Corpo da classe
}
Essa já é mais chata de explicar. Vamos tentar… A classe é um possível objeto a ser criado. Quando você extende uma classe você pode sobrepor todos ou nenhum método dessa classe e, além disso, você pode usar todos os métodos e variáveis da classe extendida (desde que não sejam static) como se fossem métodos da classe filha. Uma interface é um “modelo”, ou seja, quando você implementa uma interface você TEM que sobrepor todos os seus métodos.
Os chamados getters e setters são métodos criados por nós mesmos para nos auxilixar. São para obter o valor de uma variável de instância (getter) ou para setar um valor a uma variável de instância (setter).
Ex.:
[code]class Exemplo{
String nome;
int idade;
public void setNome(String n){
nome = n;
}
public String getNome(){
return nome;
}
public void setIdade(int i){
idade = i;
}
public String getIdade(){
return idade;
}
}[/code]
Espero que tenha ajudado… Caso ainda tenha alguma dúvida poste aí…
Abraços,
Os getters e setters não tem bem uma função de auxiliar. Não é principal função.
A principal é a questão de encapsulamento e segurança. Pra não ter que deixar as variaveis publicas, o melhor jeito é criar um getter (que pega o valor da variavel) e um setter.
Ex:
imagine que você fez uma classe que tem uma variavel publica chamada quadTamanho do tipo inteiro.
Agora imagine, que algum programador louco descuidado (mais que você) disse o seguinte em outro metodo:
Classe.quadTamanho = -5;
Então, existe alguma caixa com tamanho -5? Não!
Essa é a função básica, segurança.
Objeto é a classe em si ou é o p? -.-
Pessoa p = new Pessoa(); //Aqui é criado um objeto e a variável p referencia esse objeto Variaveis do tipo public sao as que fica rodando o programa inteiro ne?
Abraços
[quote=blackfalcon]Objeto é a classe em si ou é o p? -.-
Pessoa p = new Pessoa(); //Aqui é criado um objeto e a variável p referencia esse objeto Variaveis do tipo public sao as que fica rodando o programa inteiro ne?
Abraços
[/quote]
Uma classe é um modelo de como um objeto deve ser, ou seja, é um arquivo texto escrito em linguagem java que diz quais são os métodos e atributos que o objeto deve possuir…
O objeto é uma instância da classe na memória, ou seja, é uma posição da memória que guarda uma classe como a definida acima com os seus atributos e métodos com valores específicos…
O p no caso é uma variável que aponta para a posição de memória onde estão guardados os dados do objeto…
Variáveis do tipo public fazem parte do que se chama de modificadores de acesso, esses podem ser private, protected, public e default (package que é sem modificador)…
O modificador é uma palavra reservada da linguagem, e siginifica o seguinte
private - um método ou atributo pode ser enxergado apenas dentro da própria classe
protected - um método ou atributo pode ser enxergado apenas dentro da própria classe e também dentro das classes filhas - aquelas que usam o extends
default - sem modificador - um método ou atributo pode ser enxergado dentro da própria classe e também dentro de qualquer uma das classes do mesmo pacote
public - um método ou atributo pode ser enxergado em qualquer classe da aplicação
[]´s
Desculpa, Sergio Figueras, mas sua vontade de corrigir algo te deixou escapar um detalhe.
Quando você encapsula algo, como no seu exemplo você utiliza os getters e setters para te auxiliar nesse encapsulamento.
Não quis dizer que você cria esses métodos de bobeira, pra ajudar, mas nesse sentido que você falou.
Abraços,
Pimenta,
Não entendi o seu ponto. Você pode explicar denovo?
Grato.
Resumindo:
Quando eu disse que cria pra te auxiliar não quis dizer que você cria quando quer.
Ué, mas é claro. Getters e setters tem função ligada ao encapsulamento - Setar variaveis private. Talvez não tenha sido bem claro no meu reply.
Não não, você foi claro. Eu que não fui…
Abraços,
Mesmo no protected, o método ou atributo também pode ser enxergado por classes do mesmo pacote.
O java é bastante permissivo quando se trata do mesmo pacote.
No caso, o protected é mais permissivo que o default, já que classes filhas, mesmo as de outro pacote, poderão enxergar o atributo/método.
Ok, há uma longa e detalhada explicação sobre a diferença entre classes e interfaces a partir desse post:
http://www.guj.com.br/posts/list/51866.java#273117
Correto, quis dizer que o protected tem a ver com herança (ou seja, classes de mesma hierarquia e outros pacotes tb são vizeis… o certo ficaria
public > protected > default (package) > private ->> da esquerda pra direita diminui a visibilidade.. []s
De nada vai adiantar se um programador descuidado fazer o seguinte:
public class Setter{
public static void main(String args[]){
ObjCaixa caixa = new ObjCaixa();
caixa.setQuadTamanho(-5);
}
}O fato é que em ambos os casos deve haver consistência de dados!!! O que vcs acham :?:
[quote=erich2008]Boa noite, após baixar vários PDFs, manuais e apostilas tenho dúvida ainda em alguns termos;
diferença entre variável de instância e de referência
diferença entre implements e extends
diferença entre classes e interfaces
diferença entre getters e setters
alguém poderia ajudar?[/quote]
Vc poderia começar por aqui:
http://guj.com.br/artigos.jsp
Mais precisamente:
http://guj.com.br/java.tutorial.artigo.123.1.guj
:idea: Aconselho a ler primeiro algum conteúdo sobre orientação a objeto.
[quote=Allan_BSO][quote=Sergio Figueras]
Ex:
imagine que você fez uma classe que tem uma variavel publica chamada quadTamanho do tipo inteiro.
Agora imagine, que algum programador louco descuidado (mais que você) disse o seguinte em outro metodo:
Classe.quadTamanho = -5;
Então, existe alguma caixa com tamanho -5? Não!
[/quote]
De nada vai adiantar se um programador descuidado fazer o seguinte:
public class Setter{
public static void main(String args[]){
ObjCaixa caixa = new ObjCaixa();
caixa.setQuadTamanho(-5);
}
}O fato é que em ambos os casos deve haver consistência de dados!!! O que vcs acham :?:
[/quote]
Se nao deixar a variavel acessivel para todas as classes adianta sim… creio eu que possa ser colocado um if no set…
public void setQuadTamanho(int numero)
{
if ( numero > 0)
{
quadTamanho = numero;
}
}Se estiver errado, alguem me corrija 
Abraços
Certíssimo. Sem consistência não há encapsulamento. Outra forma de quebrar um encapsulamento é retornar um objeto no set. Veja:
[code]public class Boletim {
List notas = new ArrayList();
public void adicionarNota(float nota) {
if (nota < 0 || nota > 10)
throw new IllegalArgumentException(“Nota inválida!”);
notas.add(nota);
}
public List getNotas() {
return notas; //Péssima idéia
}
}[/code]
Agora é possível fazer:
Boletim b = new Boletim();
b.getNotas().add(-10.0f); //Aceita!
Se a idéia era só fazer iteração, o método getNotas() deveria ser implementado assim:
public List<Float> getNotas() {
//Retorna uma versão imodificável da lista
return Collections.unmodifiableList(notas);
}
Ou assim:
public List<Float> getNotas() {
//Retorna uma cópia da lista
return new List<Float>(notas);
}
Outra forma comum de quebra do encapsulamento é receber a lista externamente. Por exemplo, considere o seguinte construtor alternativo para a classe boletim:
public Boletim(List<Float> lista) {
for (float f : lista) {
if (f < 0 || f > 10) {
throw new IllegalArgumentException("Nota inválida!");
}
}
this.notas = lista; //Péssima idéia.
}
Aqui, estamos criando um boletim com uma referência a uma lista interna. Então é possível fazer:
List<Float> notas = new List<Float>();
Boletim b = new Boletim(notas);
notas.add(-10); //Adicionou em boletim também!!!
O correto seria fazer uma cópia:
public Boletim(List<Float> lista) {
for (float f : lista) {
if (f < 0 || f > 10) {
throw new IllegalArgumentException("Nota inválida!");
}
}
this.notas = new ArrayList<Float>(lista); //Péssima idéia.
}
O exemplo foi usado com Lists, mas vale para qualquer objeto de qualquer classe. Note que se o objeto fosse imutável (como é o caso do String), essa observação não se aplica. Também por isso dizemos que esse tipo de objeto torna o design mais simples.
Outra coisa é fazer a consistência, mas deixar a lógica desencapsulada. Em alguns casos, é melhor que o set seja substituído por um método mais conveniente. Vamos ao exemplo clássico. Considerem a seguinte classe, que representa um semáforo (desses de trânsito mesmo):
[code]public class Semaforo {
private Color cor = Color.RED;
public void setCor(Color novaCor) {
if (this.cor == Color.RED && novaCor != Color.GREEN)
throw new IllegalArgumentException(“De vermelho tem que ir para verde!”);
if (this.cor == Color.YELLOW && novaCor != Color.RED)
throw new IllegalArgumentException(“De amarelo tem que ir para vermelho!”);
if (this.cor == Color.GREEN && novaCor != Color.YELLOW)
throw new IllegalArgumentException(“De verde tem que ir para amarelo!”);
this.cor = cor;
}
public void getCor() {
return cor;
}
}[/code]
Notem que aqui existem gets e sets e set faz a validação correta. Não é possível atribuir uma cor inválida. Logo, a classe está encapsulada, certo?
Errado. O atributo está encapsulado, mas a lógica do seu uso não.
Imagine que no seu código você usa a classe semáforo e precisa trocar a cor do semáforo.
if (semaforo.getCor() == Color.YELLOW)
semaforo.setCor(Color.RED);
else if (semaforo.getCor() == Color.GREEN)
semaforo.setCor(Color.YELLOW);
else if (semaforo.getCor() == Color.RED)
semaforo.setCor(Color.GREEN);
O que aconteceu aqui? Esse if faz parte da lógica do semaforo. Mas por nosso set ser “aberto”, a lógica acabou ficando de fora da classe semáforo!!! Se seu semáforo for usado em vários pontos do seu código, esse if vai, certamente, se repetir. Depois de um tempo, se você quiser alterar a ordem do semáforo, ou se uma nova cor surgir, você terá um sério problema. Terá que identificar todos os pontos onde um if desses ocorre e alterar.
O correto seria não fazer um set e encapsular também a lógica do atributo. Veja a nova versão da classe:
[code]
public class Semaforo {
private Color cor = Color.RED;
//Não damos mais a opção de dizer a nova cor.
//O semáforo é quem deve saber isso.
public void trocaCor() {
if (cor == Color.RED)
cor = Color.GREEN;
if (cor == Color.YELLOW)
cor = Color.RED;
if (cor == Color.GREEN)
cor = Color.YELLOW;
//Não era nenhuma dessas? Tem coisa errada. Melhor fazer um assert.
assert(false);
}
public void getCor() {
return cor;
}
}[/code]
O assert é uma boa prática de programação, mas não vem ao caso agora.
O uso desse semáforo vai ser mais confortável e mais seguro. Agora, quem precisar trocar a cor de um semáforo no código só precisa fazer:
semaforo.trocaCor();
As troca sempre estará correta. Também será fácil adicionar novas cores ou mudar a ordem de cores desse semáforo, já que a lógica não ficou exposta.