A classe Account possui uma classe filha, nao abstrata chamada PersonalAccount.
publicclassSavingAccountextendsAccount
O que nao entendendo é que apos ter implementado a interface Comparable e o metodo CompareTo na classe mae Account, comecei a ter um erro na classe filha PersonalAccount obrigando a mesma implementar o metodo CompareTo tambem.
Alguem poderia me ajudar a entender por favor. Muito obrigado!
ou seja… é comparavel a qualquer coisa que extenda Account
ViniGodoy
Você pode colocar a mensagem de erro? Estranho, pq ela não deveria estar aparecendo.
ViniGodoy
Esquece. O problema é que o método chama-se compareTo não CompareTo. O "c" da palavra compare é minúsculo.
Para evitar esse tipo de problema, use o annotation @Override. Isso fará com que o compilador verifique se o método que você declarou está mesmo fazendo override de um método de uma classe ou interface, e apresente um erro caso não esteja. No seu caso, você acabou declarando um novo método, por isso ele exigia que você declarasse o método da interface (compareTo com “c” minúsculo) na classe filha.
@Override
public int compareTo(Account account){
if(this.getBalance() < account.getBalance()){
return -1;
}
if(this.getBalance() > account.getBalance()){
return 1;
}
return 0;
}
Uma forma mais simples de implementar esse mesmo método é:
@Override
public int compareTo(Account account){
return this.getBalance() - account.getBalance();
}
H
HotBoyRZ
Nossa, era mesmo um erro de sintaxe. Muito obrigado ViniGodoy.
E obrigado tambem Lavieri, porque usando da forma como falou o codigo ficara muito mais reutilizavel.
ViniGodoy
A forma que o Lavieri falou é aplicada em outro contexto.
Quando você tem uma List<? extends Account>, significa que você pode aceitar como parâmetro um List<Account> ou um List<SavingAccount>. Da mesma forma, você poderia ter um método setComparator na sua classe Account para trocar o comparador default que aceitasse um Comparator<? super Account>. Assim, alguém poderia fornecer para sua classe um outro Comparator<Account> ou um Comparator<Object>.
No caso de métodos, um compareTo(Account) já aceitará naturalmente um Account ou um SavingAccount, justamente por suportar polimorfismo. Por isso, não é necessário (e nem recomendado) usar os wildcards.
Lavieri
ViniGodoy:
A forma que o Lavieri falou é aplicada em outro contexto.
Quando você tem uma List<? extends Account>, significa que você pode aceitar como parâmetro um List<Account> ou um List<SavingAccount>. Da mesma forma, você poderia ter um método setComparator na sua classe Account para trocar o comparador default que aceitasse um Comparator<? super Account>. Assim, alguém poderia fornecer para sua classe um outro Comparator<Account> ou um Comparator<Object>.
No caso de métodos, um compareTo(Account) já aceitará naturalmente um Account ou um SavingAccount, justamente por suportar polimorfismo. Por isso, não é necessário (e nem recomendado) usar os wildcards.
justamente…
é que li rapidamente… e os Comparators (e não os Comparables) são normalmente tipados desta foram…
nesse caso ai não há necessidade dessa tipologia…
era o @Override mesmo ^^ q ajudaria mesmo a não cair nesse problema
sergiotaborda
HotBoyRZ:
Tenho uma classe abstrata Account que implementa a interface Comparable:
Não é totalmente correto fazer isso. Comparable deve ser implementado na classe filha, não na classe pai.
Antigamente não tinha problema tecnico com esse erro, o compilador aceitava. Mas hoje ele não aceita e com razão.
Vc pode definir o método na classe abstrata que aceita qq tipo de conta, mas Comparable deve ser colocado na classe filha.
