Pergunta de entrevista - parece fácil mas não é...

This message was edited 2 times. Last update was at 11/07/2011 17:04:11

ViniGodoy wrote:

saoj wrote:Claro que essa resposta é errada, né? Um Student diferente foi eliminado do Set sem qualquer cabimento. A tua resposta está certa, mas eu usario o equals dentro do compare, só para enfatizar que eles precisam ser coerentes.

Não concordo. Em momento nenhum o enunciado diz para que serve esse método, ou o critério de desempate.

Como eu falei, se um avaliador realmente queria isso, estava testando se o programador estava atento a pegadinha. Na prática, qualquer um que estivesse programando o método saberia se pode ou não eliminar estudantes, ou qual seria o critério de desempate, caso as idades fossem iguais (isso também não foi informado).

Não Vini. O método EQUALS estava lá para te dizer que dois estudantes com ID diferentes são objetos DIFERENTES. Esse é o critério que te diz se um estudante é igual ao outro ou não. O seu comparator tinha que obrigatoriamente respeitar isso. Um set armazena estudantes DIFERENTES. O seu set ficou totalmente quebrado porque ele passou a eliminar um estudante de forma totalmente errado. O método equals está ali para te dizer isso.

ViniGodoy wrote:

saoj wrote:Quando vc usa comparator ou comparable, o método equals é IGNORADO e o hash/set usa compare/compareTo. Eu não sabia disso até pouco tempo.

Disso eu sabia.

Sabia mas criou uma inconsistencia braba entre o equals e o compareTo. Isso é um erro grave.

Eu ainda acho a sua reposta não ideal. Eu prefiro usar equals claramente dentro do compareTo, para não deixar margem para inconsistencias. A regra é clara: compareTo tem que ser consistente com equals.

Vai ser 3 ticks do clock mais lento... tem razão... alguns nanosegundos... não muitos...

Zeed01 wrote:Boa noite galera !

saoj

Porque meu código esta errado ?
Qual é afinal a finalidade ?
A saída para o código que enviei foi:

[Student id=2;age=18]
[Student id=1;age=20]
[Student id=4;age=20]
[Student id=3;age=22]

Se não é isso que o exercício queria, então não entendi o enunciado...
Pode me explicar por favor ?

Obrigado.

[]s

O seu programa pode até funcionar, mas vc criou um comparator estranho que te dá:

s1 > s2 AND s2 > s1

para o caso de vc ter dois estudantes diferentes com a mesma idade.

Pergunta de entrevista trivial, hein?

Virtual Machine Man Membro desde: 27/10/2006 16:44:29 Mensagens: 668 Offline

Boa noite Galera !

Ok saoj, você utilizou o equals ao invés de repetir a comparação dos id´s... mas no final o seu codigo funciona da mesma forma que o meu.

[]s

This message was edited 1 time. Last update was at 11/07/2011 17:07:19

saoj wrote:

Zeed01 wrote:Boa noite galera...

Considerando que esta usando o Set, como o Vini já falou, a resposta dele me parece correta, para mim também não ficou claro no enunciado o caso de idades iguais...
De qualquer forma uma solução, digamos, mais didática seria:

if (s1.age == s2.age) { if (s1.id != s2.id) { return 1; } return 0; } else if (s1.age > s2.age) { return 1; } else { return -1; }

[]s

Isso tá errado.

Esta errado porque? No resultado aparecem os 4 malandros:
[Student id=2;age=18]
[Student id=1;age=20]
[Student id=4;age=20]
[Student id=3;age=22]

[edit]Putz, demorei pra responder! Agora vi a resposta ali em cima [/edit]

This message was edited 1 time. Last update was at 11/07/2011 17:09:39

Não vejo porque a regra do equals e do compareTo tenha que ser idêntica. O próprio Effective Java ressalta que devemos ter cuidado, pois a condição de que objetos "equals" terem compareTo == 0 é apenas no caso de ordenação natural, e pode não ser válida sempre.

Não há qualquer regra no Java, explícita ou implícita, que exija que um comparator retorne 0 em dois objetos que são equals. Esse critério é deixado livre, justamente para que se possa agrupar os objetos em conjuntos de acordo com a sua conveniência, e para que o Comparador crie regras de ordenação e eliminação próprias.

Por isso, ainda acho o enunciado tendencioso e discordo da sua resposta. Se essa era uma regra de negócio, deveria estar explícita no enunciado. Caso contrário, da margem a qualquer interpretação.

sergiom wrote:

saoj wrote:

Zeed01 wrote:Boa noite galera...

Considerando que esta usando o Set, como o Vini já falou, a resposta dele me parece correta, para mim também não ficou claro no enunciado o caso de idades iguais...
De qualquer forma uma solução, digamos, mais didática seria:

if (s1.age == s2.age) { if (s1.id != s2.id) { return 1; } return 0; } else if (s1.age > s2.age) { return 1; } else { return -1; }

[]s

Isso tá errado.

Esta errado porque? No resultado aparecem os 4 malandros:
[Student id=2;age=18]
[Student id=1;age=20]
[Student id=4;age=20]
[Student id=3;age=22]

[edit]Putz, demorei pra responder! Agora vi a resposta ali em cima [/edit]

http://www.guj.com.br/java/247060-pergunta-de-entrevista/2#1281010

Virtual Machine Man Membro desde: 27/10/2006 16:44:29 Mensagens: 668 Offline

Boa noite galera,

saoj, desculpe minha ignorancia...

Mas pode explicar isso: s1 > s2 AND s2 > s1

E porque ou seu código não cai na mesma situação que o meu...

Lembrando que, concordo que, para mim, utilizar o equals ao inves de repetir a comparação dos id´s é o mais correto

[]s

Virtual Machine Man Membro desde: 27/10/2006 16:44:29 Mensagens: 668 Offline

Boa noite galera !

Concordo com o Vini, fazendo isso:
Voce esta considerando que o id é o critério de desempate para o caso de idades iguais, e isso não esta explicito no enunciado, da mesma forma que outra regra qq poderia ser considerada, por exemplo a de que o primeiro objeto a ser inserido deve vir primeiro na ordenação.

[]s

This message was edited 2 times. Last update was at 11/07/2011 17:56:43

ViniGodoy wrote:
Não há qualquer regra no Java, explícita ou implícita, que exija que um comparator retorne 0 em dois objetos que são equals. Esse critério é deixado livre, justamente para que se possa agrupar os objetos em conjuntos de acordo com a sua conveniência, e para que o Comparador crie regras de ordenação e eliminação próprias.

API wrote:
It is strongly recommended (though not required) that natural orderings be consistent with equals. This is so because sorted sets (and sorted maps) without explicit comparators behave "strangely" when they are used with elements (or keys) whose natural ordering is inconsistent with equals. In particular, such a sorted set (or sorted map) violates the general contract for set (or map), which is defined in terms of the equals method.

Fonte: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Comparable.html

API wrote:
The ordering imposed by a comparator c on a set of elements S is said to be consistent with equals if and only if c.compare(e1, e2)==0 has the same boolean value as e1.equals(e2) for every e1 and e2 in S.

Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals to order a sorted set (or sorted map). Suppose a sorted set (or sorted map) with an explicit comparator c is used with elements (or keys) drawn from a set S. If the ordering imposed by c on S is inconsistent with equals, the sorted set (or sorted map) will behave "strangely." In particular the sorted set (or sorted map) will violate the general contract for set (or map), which is defined in terms of equals.

Fonte: http://download.oracle.com/javase/6/docs/api/java/util/Comparator.html

A regra é clara. Quebrar o contrato do objeto para EQUALITY no seu comparator vai quebrar o seu programa inteiro porque um TreeSet ou um TreeMap vão ficar quebrados. Acho que até um HashMap vai se ferrar porque ele vai usar o compareTo do comparator para decidir sobre equality, e NÃO o equals, ou seja, vai se ferrar bonito. (Essa última afirmacao do HashMap eu não tenho certeza, mas apostaria...)

UPDATE: Num HashMap não tem problema nenhum (caso vc use a interface Comparable). Ele vai sempre pelo hashCode and equals. O problema é realmente só nas collections ordenadas, TreeMap e TreeSet, porque eles ignoram o hashCode e o equals e usam APENAS o compareTo ou o comparable.

Zeed01 wrote:Boa noite galera,

saoj, desculpe minha ignorancia...

Mas pode explicar isso: s1 > s2 AND s2 > s1

[]s

Isso é uma aberracao lógica. Mas o teu código gera essa expressão, ou seja, s1 é maior que s2 ao mesmo tempo que s2 é maior que s1. Tem que usar os IDs para desempatar idades iguais.

This message was edited 1 time. Last update was at 11/07/2011 17:27:35

Boa noite Galera,

saoj, utlizar o id para desempatar não é o que você esta fazendo aqui:

return s1.id - s2.id;

?

Eu entendi o que você quis dizer, e concordo, só não concordo em afirmar que esta claro no enunciado que o Id é o critério de desempate...

[]s

This message was edited 1 time. Last update was at 11/07/2011 17:41:45

Zeed01 wrote:Boa noite Galera,

saoj, utlizar o id para desempatar não é o que você esta fazendo aqui:

return s1.id - s2.id;

?

Eu entendi o que você quis dizer, e concordo, só não concordo em afirmar que esta claro no enunciado que o Id é o critério de desempate...

[]s

Aí o cara tem que ser esperto para sacar que como critério de desempate vc tem que usar algum campo ÚNICO, se nao vc pode sempre cair novamente num empate. O ID é esse campo. Se fosse uma String vc teria problemas, porque hashCode não é obrigatoriamente único. E note também que como as idades são iguais, não interessa muito quem é maior que quem, desde que vc não crie uma aberracao lógica não-deterministica.

Virtual Machine Man Membro desde: 27/10/2006 16:44:29 Mensagens: 668 Offline

Boa noite galera !

Bom parabéns pela sua esperteza.
Aproveitando, acho que não precisa ser tão esperto para entender que o intuito do forum é a troca de informações e a ajuda mutua, passando sempre pela boa educação...

[]s

Zeed01 wrote:Boa noite galera !

Bom parabéns pela sua esperteza.
Aproveitando, acho que não precisa ser tão esperto para entender que o intuito do forum é a troca de informações e a ajuda mutua, passando sempre pela boa educação...

[]s

Eu não só fui educado como falei que errei essa questão quando ela me foi apresentada. Compartilhei para outros aprenderem com o meu erro.

Tentando entender o contra-argumento do pessoal aqui, vcs querem dizer que não ficou claro no enunciado se o Set deveria armazenar APENAS idades diferentes? Poderia até ser mas é muita forcacao de barra vcs não acham? O enunciado diz:

Você tem um objeto Student que precisa ser armazenado num Set e ordenado por idade.

Em nenhum momento ele fala que o set teria apenas IDADES DIFERENTES. Ele fala que o set precisa ser ordenado por idade, e só. Se eu vou colocar estudantes num set, vc tem que assumir que vc tá usando um set para não ter estudantes repetidos ali dentro, certo? Nada a ver com idade e set.

Notícias, artigos e o maior fórum brasileiro sobre Java