Isso aih… Você somente deve utilizar o Boolean caso queira, no retorno do método, efetuar uma nova consistência (em geral para exibir uma mensagem ao usuário). Como no exemplo de nosso colega, quando retornasse false fariamos o seguinte:
boolean consiste = conta.setPoupanca(500);
if (consiste)
System.out.println("Saldo atualizado com sucesso");
else
System.out.println("Não foi possível atualizar a conta");
private double saldo;
// Métodos acessores não devem conter lógicas de negócio, por isso mantive-os
// no padrão.
public void setSaldo(double newSaldo) {
this.saldo = newSaldo;
}
public double getSaldo() {
return this.saldo;
}
/*
* considerei duas lógicas para este método:
* - ou seu professor considerou apenas um método para sacar e depositar
* (passando um valor negativo como valor), e o valor boolean serviria
* para informar o saldo está positivo ou não.
* - ou caso o saldo esteja negativo, após um depósito ele pode continuar
* negativo, neste caso (e somente neste) o retorno seria false.
*/
public boolean depositaValor(double valor) {
this.saldo += valor;
return this.saldo >= 0;
}
Eu creio que colocar um método “setter”, dessa forma é uma violação (um tanto grave) do encapsulamento.
Aliás, o princípio de se usar um método acessor, e não o atributo diretamente, é justamente a possibilidade de fazer verificações nesse método, não somente garantir o encapsulamento do tipo da representação interna do dado.
Me parece bastante inseguro (e imprudente) ter um método de set que “engula” um novo saldo.
Quanto mais um setter que não verifica detalhes como se o novo saldo é possível ou quem fez esse tipo de operação.
Além disso, uma operação como essa não poderia ser feita sem uma justificativa forte, talvez passando também algum tipo de ordem de serviço, com autorização de alguém com grande poder na empresa.
Em resumo… no caso de um trabalho, é melhor ficar só que foi proposto, um método de “deposito” e outro de “saque” mesmo.
[quote=ViniGodoy]Eu creio que colocar um método "setter", dessa forma é uma violação (um tanto grave) do encapsulamento.
Aliás, o princípio de se usar um método acessor, e não o atributo diretamente, é justamente a possibilidade de fazer verificações nesse método, não somente garantir o encapsulamento do tipo da representação interna do dado.
Me parece bastante inseguro (e imprudente) ter um método de set que "engula" um novo saldo.
Quanto mais um setter que não verifica detalhes como se o novo saldo é possível ou quem fez esse tipo de operação.
Além disso, uma operação como essa não poderia ser feita sem uma justificativa forte, talvez passando também algum tipo de ordem de serviço, com autorização de alguém com grande poder na empresa.
Em resumo… no caso de um trabalho, é melhor ficar só que foi proposto, um método de "deposito" e outro de "saque" mesmo.[/quote]
concordo !!.. realmente este setter faz com que o método de depósito perca o seu sentido e a segurança da conta seja perdida… creio que com essa modificação o código ficaria melhor:
no caso do getter ele pode ficar public… já que ele não modifica a consistencia do objeto.
muito obrigado pelo toque!!
// Métodos acessores não devem conter lógicas de negócio, por isso mantive-os
// no padrão.
private void setSaldo(double newSaldo) {
this.saldo = newSaldo;
}
e claro… ele precisa ser utilizado em algum lugar:
Agora está perfeito. Com o método private tudo muda de figura.
Agora estamos assumindo que quem mexe no saldo é a própria classe, e não qualquer pessoa.