Eu ainda não entendo o por que dos getters e setters?

Um detalhe que vai te ajudar no entendimento tbm de getters e setters é:

SET: usado para atribuir valores, executar operações, etc…
GET: usado simplesmente para dar um retorno, levar um valor a ser impresso na tela

Tipo:


void deposita(double valor){//Está atribuindo um valor e modificando o saldo de um cliente pelo deposito
    double novoSaldo = saldo + valor;
    saldo = novoSaldo;
}

double deposita(){// Neste caso não seria interessante usar o GET, pq não existe necessidade de retornar o valor do deposito + saldo
   return deposito;
}

Espero ter ajudado brother…

Entendi, também nunca me explicaram direito isso.

Você diz que:

public int idade;

é o mesmo que

[code]
private int idade;

public int getIdade(){
return idade;
}

public void setIdade(int i) {
idade = i;
}[/code]

Uma vez que:

pessoa.idade = -1;

//dá no mesmo que

pessoa.setIdade(-1);

O certo seria encher o set de restrições conforme a sua regra, o problema é o que deve ser passado caso ele digite uma idade invalida.

[code]public void setIdade(int i){
if( i < 0 )
throw new IllegalArgumentException(“Idade negativa nao existe”);
idade = i;

}[/code]

Mas é certo colocar exceções em sets e gets?
Como agora estou usando o JSF, me surgiu essa dúvida também, pois o que vemos são códigos inúteis, no caso do que os IDEs geram sozinho. Aquilo dá no mesmo que ser público.

O ideal seria ter o property mesmo, como Urubatan diz no inicio da Thread. O triste são frameworks que usam CoC com get/set e não permitem configuração para alterar isso.

Outra razão que li em um livro de design pattern é que antigamente, quando não se tinha a ajuda das IDE’s, fazer o acesso via get e set te evitaria trabalho de mexer no codigo todo, caso vc desejasse mudar o nome do atributo dentro da classe, pois os nomes dos métodos continuariam os mesmos.

[quote=urubatan]na verdade estas tags funcionam com métodos de qualquer nome, des de que tu utilize a outra gambiarra padronizada, nem tão famosa quanto os gets e sets, mas que também faz parte da API de JavaBeans …
se tu criar uma classe BeanInfo pode usar qualquer nome para os metodos de leitura e escrita das tuas propriedades que as ferramentas vão se achar normalmente …
pois a classe BeanInfo vai informar para estes “consumidores” do bean, quem é o método de escrita e o metodo de leitura desta propriedade …
a unica diferença é que se tu não criar um beaninfo, o java vai criar um default que utiliza o padrão de nomenclatura get/set para as propriedades[/quote]
Boa!!!