Mensagens enviadas por: faelcavalcanti
Índice dos Fóruns » Perfil de faelcavalcanti » Mensagens enviadas por faelcavalcanti
Autor Mensagem
Maurício Linhares wrote:Veja que ele manda executar "java Miner.java", ele nem compilou ainda e mandou a JVM executar o arquivo texto com o código fonte.

Poxa cara, que mancada feia eu dei.

Nem prestei atenção a isto. Valeu mesmo Maurício, vou ficar de olhos mais atentos a pequenos detalhes.

Maurício Linhares wrote:Você deu o comando no código e ele funcionou? Tem certeza?

Porque faltou definir o classpath na linha de comando.


Não tenho certeza, mas como faço este procedimento utilizando o eclipse ?

Também andei efetuando uma vistoria sobre possíveis erratas quanto ao livro mas mesmo assim não corresponde, tampouco algum comentário.

Segue abaixo as erratas mediadas por Bert Bates.
Fala pessoal, estou martelando quanto a uma questão do livro de kathy voltado para o exame (310-055). Para quem possui o livro é a questão 15 da página 397, para os que não possui segue abaixo o seu enunciado:

Given:



And the command-line invocation:
java Miner.java

What is the result?

A. null
B. null null
C. A ClassCastException is thrown.
D. A NullPointerException is thrown.
E. A NoClassDefFoundError is thrown.
F. An ArithmeticException is thrown.
G. An IllegalArgumentException is thrown.
H. An ArrayIndexOutOfBoundsException is thrown.


Adivinhem, mas a resposta é a letra E, e por mais incrível que pareça.
Se vocês colocarem para rodar este código, verão que não acontecerá nenhuma exceção ou erro conforme resposta certa.

De certa forma estou indignado com a resposta, pois não consegui simular esta situação. Fiquei pensando depois, será que porque como estou utilizando o eclipse, de alguma forma posso estar fazendo algo errado.

Efetuei a seguinte modificação e mesmo assim o resultado é o mesmo. Vejam:



faelcavalcanti wrote:Ocorre o mesmo no uso de covarância quando tenta-se aplicar o polimorfismo, em que acontece em tempo de runtime, mas isso é só um exemplo.


Quando mencionei sobre covarância, errei quanto ao que disse que ocorre o mesmo. Na verdade é uma outra situação, mas que aparentemente temos o mesmo problema se não seguirmos o tipo estabelecido ou o que foi definido.

Um exemplo disto seria se um método da superclasse declarasse que levantaria uma exceção do tipo IOException, já na subclasse o mínimo que você poderia fazer seria redeclarar para um FileNotFoundException ou omitir a declaração de throws, e talvez efetuando o tratamento, neste caso específico na reimplementação, ou seja, efetuando o override.

Contudo é só um exemplo que tentei dar, mencionando que podemos atribuir uma implementação utilizando a própria classe ou uma subclasse e não uma superclasse como tipo declarado. Ok!
Pensando na mesma implementação que você veio seguindo organizei da seguinte forma:

Da forma que se encontra o código, ocorrerá o mesmo problema mencionado.

Você terá total liberdade para declarar a variável revisores, conforme fiz no método main, como abaixo:
Collection<Revisor> revisores = new HashSet<Revisor>();
Mas para atribuir para o método setRevisores, terá que estabelecer o contrato definido pelo método.

Por exemplo, dê uma olhada nesta implementação que fiz agora:



Apesar de não utilizar uma implementação de até uma outra subclasse, você poderá ver que o problema é o mesmo.

The method setAnimal(Mamifero) in the type CadeiaAlimentar is not applicable for the arguments (Animal)


Isto consiste por conta do contrato estabelecido pelo método setAnimal, ou seja, como declarei a assinatura do método para Mamifero, acabei restrigindo o tipo de instância que gostaria de receber em meu método setAnimal.

Quando criei a variável cachorro do tipo Animal, acabei quebrando o contrato estabelecido pelo método. Apesar de mamífero implementar a interface animal, não cabe a mim ampliar a restrição estabelecida pelo método.

Ocorre o mesmo no uso de covarância quando tenta-se aplicar o polimorfismo, em que acontece em tempo de runtime, mas isso é só um exemplo. Quanto ao uso de Generics, está perfeito, o problema persiste apenas no contrato do método, pois a intersecção não equivale ao esperado.

Espero ter ajudado.
raf4ever wrote:

Estou com medo de fazer a certificação e ficar desatualizado muito rápido
Quanto a isso,nao acho q deva ser uma preocupação,pois apesar das sucessivas versões da prova,o conhecimento agregado com a certificação é permanente;acho que, melhor do que "viver de upgrades",é mais interessante partir pra outras certificações,e aumentar seu leque de conhecimento


Concordo plenamento. Para os que já têm o SCWCD não esperem pelo SCWCD 1.5 da JEE5, aprimorem pelas certificações da IBM, Oracle ou até Microsoft. O mais importante é agregar valores e experiências profissionais, contando com os projetos em que tenha participado ou que possam participar futuramente, e com estas certificações que prevalecem a maturidade no que se têm focado juntamente com o sua graduação, mestrado e porque não até um doutorado.

Não entendi bem ao certo qual seria o problema, mas aparentemente a questão do uso do widening, é para que não haja a necessidade de se ter que criar outro método, já que o overload ocorre em tempo de compilação. O mesmo pode acontecer utilizando-se objetos, desde que estejam na mesma "árvore de herança".

A prioridade para que a máquina virtual identifique qual o método que será executado será pelo uso de widening, autoboxing e posteriormente o uso de var-args.

O que dificultou um pouco também foi quanto ao uso com generics, pois agora temos diversas técnicas e cuidados a termos na prova em questões de sintaxe e execução quanto ao uso do override e overload.

Que venham as questões de drag-and-drop, teríamos que levantar uma estimativa de tempo para cada questão deste tipo.
brunohansen wrote:XXXXXXXXXXXXXXX Post Sensurado so falei merda XXXXXXXXXXXXXXXXXX


Pode ser merda para você, o que implica também que pode ser uma dúvida de uma outra pessoa e que é um dos tópicos a se ter mais cuidado.
Fala pessoal. Estou com uma dúvida danada quanto ao uso do overload em conjugado com as situações: [widening], [Autoboxing] e [Var-args].

Porém, estive revisando o livro de kathy sierra, voltado para o exame (310-055) e peguei o seguinte exemplo:

Em que ele executa sem problemas a saída, em que até aí não é surpresa nenhuma:
long...
Integer...

Como o assunto tratado é sobre overload, a idéia seria manter o mesmo nome do método modificando a sua assinatura, no caso a lista de argumentos, justificando corretamente o seu uso.

Visando isto, efetuei algumas mudanças no código acima, para que tenha-se o mesmo nome do método e não diferente. Vejam abaixo:

O problema está na linha:
box_vararg(x, y); // needs to box and use var-args

em que o compilador alegremente me informa:
The method box_vararg(long[]) is ambiguous for the type Vararg

Segue abaixo as especificações quanto ao uso do overload avançado, retirados diretamente do livro:
As we can see, you can successfully combine var-args with either widening or boxing. Here's a review of the rules for overloading methods using widening, boxing,
and var-args:

* Primitive widening uses the "smallest" method argument possible.
* Used individually, boxing and var-args are compatible with overloading.
* You CANNOT widen from one wrapper type to another. (IS-A fails.)
* You CANNOT widen and then box. (An int can't become a Long.)
* You can box and then widen. (An int can become an Object, via Integer.)
* You can combine var-args with either widening or boxing.

Minha preocupação agora seria com as questões do tipo drag-and-drop, em que é quase certa uma coisa típica destas, mas talvez eles abordem juntamente com o uso de generics, sei lá!

Contudo minha dúvida, a princípio baseia-se em como tentar efetuar a compilação e execução do meu código modificado.
andersonlfl wrote:A única coisa que eu não gostei no Head & First - Servlets e JSP é que os capítulos não são de acordo com os temas da prova da certificação como era no livro da Kathy Sierra pra SCJP. Mas de resto, eh ótimo.

Também achei o Head First um pouco diferente a didática em relação ao livro preparatório para o exame (310-055), ele está totalmente convergido nos objetivos e vitalizando detalhes para a prova de certificação.

Espero que na próxima versão o pessoal der a mesma reforçada que deram no livro de SCJP 5.0.

Valeu Felipe pelas explicações. Tive uma certa preocupação quanto a este tipo de questões, pois como as de Garbage Collection, são sempre uma questão certa na prova.

Fallow!
Também possuo este livro de certificação, SCWCD de Kathy Sierra e Bert Bates, mas gostaria de saber também se alguém possui outros livros como, Livro Guia de Java na Web Preparatório para Certificação SCWCD e SCWCD EXAM STUDY, para ter uma idéia do seu conteúdo.

Mas falando em SCWCD, alguém têm alguma novidade da SCWCD 5.0 beta que está para sair ?
Aproveitando o embalo gostaria de lançar outra questão em que também tive dificuldades sobre acoplamento no mesmo livro da página 166. Esta questão é um pouco mais complicada, porque especificamente trata-se de falar sobre baixo acoplamento, em que entendemos bem ao tratar-se de componentização. Segue abaixo a questão:


5. Select the two statements that best indicate a situation with low coupling. (Choose two.)
A. The attributes of the class are all private.
B. The class refers to a small number of other objects.
C. The object contains only a small number of variables.
D. The object is referred to using an anonymous variable, not directly.
E. The reference variable is declared for an interface type, not a class. The interface provides a
small number of methods.
F. It is unlikely that changes made to one class will require any changes in another.
Answer:
® 3 E and F are correct. Only having access to a small number of methods implies limited
coupling. If the access is via a reference of interface type, it may be argued that there is
even less opportunity for coupling as the class type itself is not visible. Stating that changes
in one part of a program are unlikely to cause consequences in another part is really the
essence of low coupling. There is no such thing as an anonymous variable. Referring to
only a small number of other objects might imply low coupling, but if each object has many
methods, and all are used, then coupling is high. Variables (attributes) in a class should
usually be private, but this describes encapsulation, rather than low coupling. Of course,
good encapsulation tends to reduce coupling as a consequence.
®˚ A, B, C and D are incorrect based on the preceding treatise.
(Objective 5.1)


Em que também errei quando fui conferir o resultado, mas gostaria de abrir aqui um debate e esclarecer de uma vez por todas a partir deste tópico.

Cito abaixo uma síntese que encontra-se no livro sobre o assunto:


Coupling and Cohesion (Objective 5.1)
* Coupling refers to the degree to which one class knows about or uses members of another class.
* Loose coupling is the desirable state of having classes that are well encapsulated, minimize references to each other, and limit the breadth of API usage.
* Tight coupling is the undesirable state of having classes that break the rules of loose coupling.
* Cohesion refers to the degree in which a class has a single, well-defined role or responsibility.
* High cohesion is the desirable state of a class whose members support a single, well-focused role or responsibility.
* Low cohesion is the undesirable state of a class whose members support multiple, unfocused roles or responsibilities.


Em que foi de grande ajuda para tentar entender os aspectos que serão abordados no exame.
Gostaria de poder discutir cada alternativa dos enunciados mencionados, ou seja, porque as alternativas certas estão certas e as erradas estão erradas.

Fallow!!!
Atualmente estou efetuando um estudo intensivo no livro de kathy sierra, voltado para certificação java, voltado para o exame (310-055), mas tive dúvidas quanto a uma questão básica, porém gostaria um pouco de esclarecimento quanto as alternativas C e E. Não entendi muito bem, mas agradeço quem puder ajudar.


1. Which statement(s) are true? (Choose all that apply.)
A. Has-a relationships always rely on inheritance.
B. Has-a relationships always rely on instance variables.
C. Has-a relationships always require at least two class types.
D. Has-a relationships always rely on polymorphism.
E. Has-a relationships are always tightly coupled.
Answer:
® 3 B is correct.
®˚ A and D describe other OO topics. C is incorrect because a class can have an instance of
itself. E is incorrect because while has-a relationships can lead to tight coupling, it is by no
means always the case. (Objective 5.5)


Neste caso a questão se encontra na página 164 para quem possui o livro. E já se encontram com as respostas como podem ver acima, porém ainda não me conformei, mesmo vendo o resultado.

Contudo possuo dúvidas apenas em entender as alternativas C e E.
Olá pessoal, estou tentando fazer o checkout do seguinte projeto a partir do link abaixo:

https://navalbattle.dev.java.net/


Neste caso queria baixar os fontes para dar uma estudada. Como já estou cadastrado no java.net, não consegui ainda baixar os fontes no eclipse. Já via alguns tutoriais como estes abaixo que estou passando mas ainda não tive sucesso.

https://eclipse-tutorial.dev.java.net/eclipse-tutorial/part2.html

Agradeço qualquer ajuda!!!
 
Índice dos Fóruns » Perfil de faelcavalcanti » Mensagens enviadas por faelcavalcanti
Ir para:   
Powered by JForum 2.1.8 © JForum Team