| Autor |
Mensagem |
|
|
erato690 wrote:E ai pessoal tudo bem gostaria de saber de algum de voçes ja fez a prova do exame da versao 6, pois esto numa parte que fala sobre regex mas nao entendi nada e é uma coisa muita chata que achei, com muito detalhes. Vi isso pela 1 vez no livro de certifiaçao gostaria de saber se cai muita coisa complesa sobre o assunto pois to tentando fazer um, exemplo aqui igual do livro mas nao vai, voçes que ja tao na area , usa muito esse tipo de linguagem por que aqui no livro estava falando que regex deveria ser tratado como uma linguagem a parte que tem uso em java.
Caiu uma pergunta de regex, muito bobinha. Mas se você acha chato talvez vai achar chato de trabalhar como programador Java. Regex é uma ferramenta valiosa no dia a dia, não só pra programação, mas para uso geral.
erato690 wrote:E e tambem sobre searilizaçao sobre os methodos writeObject e readObject que sao privados da class serializable ,tentei fazer aqui mas tambem nao foi gostaria de saber se cai sobre isso tambem na prova.
Caiu duas perguntas sobre serialização. Bem fáceis também, conceitos básicos.
As questões do livro em geral são bem difíceis em relação a prova. Estude para aprender, não para passar. Leia o livro quantas vezes for necessário e implemente algumas classes de teste. Não tenha pressa. Lembre-se que numa entrevista de emprego a certificação pode ser um peso na hora da sua entrevista. Você vai ter que mostrar conhecimento.
[]s e bom estudo.
|
 |
|
|
Se é assim de fato então porque ainda existe a idéia de "operário" entre desenvolvedores de software?
Porque a "indústria" do software é atendida por uma fila enorme de programadores operários.
No caso os desenvolvedores de software são donos de seu próprio maquinário e conhecimento, podendo por vontade própria produzir o que bem entender. Correto?
Nem sempre. Uma pequena parcela eu diria. Conheço poucos desenvolvedores com esta capacidade. A maioria continua sendo operário até a aposentadoria. Além do mais, produzir "o que bem entender" só tem valor a partir do momento que outras pessoas além dele próprio queira. Fora que o sucesso vai muito além da simples capacidade técnica.
|
|
|
|
Em primeiro lugar está faltando um "e" na seguinte linha do seu código:
Você não pode capturar uma excessão checada que nunca é lançada num bloco try...catch. InterruptedException é uma excessão checada e jamais será lançada no bloco try. O compilador sabe disso e vai reclamar.
ArrayIndexOutOfBoundsException e RuntimeException não causam problemas em ser capturadas porque não são excessões checadas, isto é, elas descendem de RuntimeException e não podem ser previstas. Estas excessões em geral são bugs no código.
Exception é abrangente demais e o compilador deixa passar porque isto inclui RuntimeException e suas descendentes. Em geral é má prática capturar Exception.
Você precisa conhecer no mínimo as classes de excessão mais básicas e saber quais são checadas ou não. Certifique-se de entender claramente estes conceitos e pratique bastante.
|
|
|
|
Se isto acontecesse de verdade acredito que a plataforma java só teria a ganhar. Java e Linux sempre apoiados abertamente pela IBM.
Eu estaria mais preocupado com relação ao MySQL que acredito não ser do interesse da IBM e poderia perder muita força.
|
|
|
|
|
Não consegui enxergar onde a resposta B utiliza polimorfismo. Consideraria apenas C e D como coretas.
|
|
|
|
|
Não são screenshots DO exame. São screenshots do ExamClear.
|
|
|
|
O que é lançado em test() não é uma Exception. O bloco try catch trata apenas caso uma Exception seja lançada. AssertionError descende de (é) um Error, não uma Exception. Se a excessão lançada em test() fosse uma IOException ou qualquer outra descendente de Exception, C estaria correto.
Seria bom você revisar este assunto e fixar bem a árvore Throwable e suas descentes Error e Exception.
|
|
|
|
Obrigado pelas respostas!
Então... o encapsulamento deve ser aproveitado inclusive na própria classe. Isto me garantirá uma manutenção menos traumática no futuro, mesmo em casos como no exemplo, onde a principio não haveria regras de controle de acesso.
Eu levantei a questão porque aqui no serviço tenho classes grandes onde há uma mistureba na forma como as variáveis privadas são acessadas dentro da própria classe, mesmo quando há métodos acessadores e isto tem dado um pouco de dor de cabeça na manutencão.
|
|
|
|
Saudações amigos do GUJ!
Essa dúvida me surgiu hoje. A implementação dos métodos da classe devem utilizar os acessadores de seus atributos ou o atributo em si? No exemplo abaixo seria (mais) correto utilizar o caso 1 ou 2?
|
|
|
|
Saudações Vagner! Em anos remotos quando eu fazia pequenas aplicações delphi com acces me deparei com este problema também. Se me lembro bem o símbolo * só funcionava para queries criadas dentro do próprio Access. Quando feitas através do ADO, as consultas seguiam o padrão SQL com símbolo %.
[]s
|
|
|
|
Algumas observações:
Você não pode declarar os métodos de interface como estáticos Eles implicitamente são publicos e abstratos e nada além disso. Já váriaveis declaradas na interface serão sempre publicas, estáticas e finais.
Ao implementar a interface numa classe, estas características permanecem verdadeiras.
Um detalhe importante: se você redeclarar uma váriável da interface numa classe que implemente esta interface, você estará ocultando a variável da interface.
Com base nestas dicas observe seu código novamente e veja onde está errando. Aconselho-o a dar uma olhada na seção Artigos aqui do site que tem um material muito bom sobre interfaces.
[]s e boa sorte!
|
|
|
|