| Autor |
Mensagem |
|
|
evertonsilvagomesjava wrote:Neste exemplo esta tendo sobreescriçao sim pq nao?
usa pra vc ver Message obj = new XMLMessage();
Vc quer dizer fazer algo assim?
Aqui não compilou... Eu acho que não é sobreescrita mesmo pois o modificador de acesso do método getText() da classe Message é o default, o que significa que somente as classes do mesmo pacote terão acesso à ele. A classe XMLMessage nem enxerga ele.
|
 |
|
|
Ainda não entendi...
Tipo, o seguinte código gera erro de compilação:
Por que entao no meu primeiro exemplo o compilador tambem nao detecta?
|
|
|
|
renzonuccitelli wrote:O instanceod serve só para perguntar se o objeto é instancia de uma determinada classe. Logo não teria porque da erro, simplesmente o print da linha 20 não será impresso.
Vc quer dizer que ele não funciona com interfaces?
|
|
|
|
Pra mim era para dar erro na linha 20, já que é impossível b ser uma instância de Fish. Alguém pode me explicar porque não gera erro de compilação na linha 20?
|
|
|
|
Given classes defined in two different files:
What is the result of executing XMLMessage.main ?
A) text
B) Compilation fails.
C) <msg>text</msg>
D) An exception is thrown at runtime
Pergunta 1: o método "getText()" não está sendo sobreescrito, correto?
Pergunta 2: No gabarito, está constando a alternativa B. Porém, eu compilei aqui, separando as duas classes certinho e funcionou normalmente, ou seja, imprimiu <msg>text</msg>
Será que o gabarito está errado mesmo ou em que fiz algo errado?
Obrigado.
|
|
|
|
A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they realize that they can reduce the number of methods in the API without losing any functionality. If they implement the new design, which two OO principles will they be promoting?
A) Looser coupling
B) Tighter coupling
C) Lower cohesion
D) Higher Cohesion
E) Weaker encapsulation
F) Stronger encapsulation
Eu ia de B e C. O que vocês acham?
|
|
|
|
entanglement wrote:
TiagoTC wrote:
Quer dizer então que podemos afirmar que em construtores essas recursões serão sempre detectadas? Eu tenho quase certeza de que já fiz um exercício que também usava this() chamando recursivamente outro construtor e que o compilador não detectava...
Poste seu exercício aqui. Pode ser que não seja fácil o compilador detectar esse caso. Lembre-se, o compilador não detecta tudo - muitas coisas não são especificadas pela JLS (Java Language Specification), portanto não precisariam ser detectadas pelo compilador. Um caso desses é a invocação recursiva de construtores, que não é especificada pela JLS e portanto nem deveria ser detectada.
É que eu não estou achando ele agora, mas vou procurar melhor durante a noite. Mas, se realmente eu não estiver enganado com relação à esse exercício, na hora do exame eu não vou saber o que colocar (erro de compilação ou execução) 
|
|
|
|
entanglement wrote:O erro é "recursive constructor invocation".
Esse erro é extremamente simples de descobrir para o compilador, porque a execução do "this()" é incondicional e deve ser feita no início do construtor.
(Tanto é que em outras linguagens, como em C++ ou C#, o equivalente ao "this" ou o "super" são postos fora das chaves, imediatamente após a declaração dos parâmetros, para enfatizar o fato de sua execução ser necessariamente imposta ANTES do bloco de código do método).
Portanto, uma análise de fluxo simples já resolve.
O compilador não é tão esperto assim como você pensa (para descobrir execuções recursivas sem critério de parada), até porque certas coisas (como rotinas mutuamente recursivas sem critério de parada) são difíceis de descobrir sem uma análise completa do ambiente de execução. Em vez disso, simplesmente o compilador se abstém de tentar descobrir tais coisas no seu código.
Quer dizer então que podemos afirmar que em construtores essas recursões serão sempre detectadas? Eu tenho quase certeza de que já fiz um exercício que também usava this() chamando recursivamente outro construtor e que o compilador não detectava...
|
|
|
|
No seguinte código:
e nesse:
O compilador gera erro de compilação pois ele detecta a recursão sem um critério de parada. Agora, nesse aqui:
Ele compila normalmente e não detecta a recursão infinita do método. Assim, eu postulei que o compilador consegue detectar recursões infinitas apenas em construtores... Porém, tenho 99% de certeza de que eu já fiz um exercício em que tinha uma recursão dessas num construtor e a resposta era "erro em tempo de execução", e não erro de compilação...
Existe alguma regra para saber quando o compilador vai detectar a recursão infinita? O meu postulado é correto?
Obrigado.
|
|
|
|
Outra coisa que me deixa com a pulga atrás da orelha é que isso não compila:
Mas isso compila:
Alguém sabe explicar o porquê?
|
|
|
|
Humm, perfeito! Eu estava confundindo dimensão com posição mesmo...
Obrigado.
|
|
|
|
No livro da Kathy Sierra está escrito a seguinte afirmação:
"If you assign an array to a previously declared array reference, the array you're assigning must be the same dimension as the reference you're assigning it to."
Porém, o seguinte código não fura essa afirmação?
Obrigado!
|
|
|
|
Excelente pontuação!  Parabéns mesmo!
Deixa eu te perguntar: com relação aquela questão que caiu do tópico que eu criei (e que você apontou no seu post), como você montou o drag-n-drop? Vc usou nextBoolean ou só next ?
PS: Qual a porcentagem da prova que tava no testkiller? Geralmente o pessoal fala que cai umas 10 questões (no máximo) igual as presentes no testkiller. Mas pelo jeito que você falou, parece que quase a prova inteira foi o testkiller!
|
|
|
|
Fiquei com uma dúvida agora no seguinte autoboxing:
Por que isso funciona normalmente? O que eu achava que acontecia era o seguinte:
1) 5 é um literal do tipo int (pois foi escrito diretamente no código fonte).
2) Assim, como Short é um tipo não primitivo, é necessário fazer o autoboxing do 5.
3) 5 é transformado em um objeto do tipo Integer.
4) Integer não é subclasse de Short, logo gera erro de compilação.
Qual o erro no racioncínio?
|
|
|
|
No livro da Kathy Sierra, está escrito a seguinte frase:
"Members accessed without the dot operator (.) must belong to the same class."
Mas, veja o seguinte código:
Aqui eu estou acessando o 'x' sem o operador '.', sendo que ele está definido na outra class (A). Isso não fura a afirmação dada pelo livro?
Obrigado.
|
|
|
|