| Autor |
Mensagem |
|
|
|
|
 |
|
|
jack_-_ganzha wrote:
sergiotaborda wrote:Na realidade o codigo necessário é apenas
Na realidade eu queria adicionar dias a um objeto Date, por isso deixei em negrito. 
Se é isso que queria então está errado de duas formas:
1) Date tem todos os get e set deprecated. Não mais devem se alteráveis. Devem ser usados apenas como VO para transporta milisegundos na epoca definida pelo java (em vez de usar long). O objeto mutável para trabalhar com datas é Calendar.
2) Mesmo que os get/set não fossem deprecated existem muitas regras ocultas no calculo correco de datas e tempos ( que ficam dentro de calendar) e portanto alterar Date directamente seria errado.
O ponto aqui é que é errado definir um date para depois o usar num calendar, defina logo o calendar e pronto. O unico uso de Calendar.setTime() é quando vc obtem Date de legados.
Uma vez retirada essas coisas desnecessárias, não é tão complexo assim.
sergiotaborda wrote:Motivos especiais:
Separação de Responsabilidade.
Internacionalização.
E o que isso tem a ver com criar coisas complicadas?
Isso levaria dias explicando....
Versão resumida: criar objeto neutro em relação ao local é muito difícil. Ainda para mais quando mexe com datas.
Dê uma olhada na API Joda-Time para ver só como é complicado quando vc decide que Calendar não é suficiente. Agora compare com a biblioteca Time and Money para ver como é fácil cometer erros e tornar os objetos não internacionalizáveis.
|
|
|
|
javaAurelio wrote:Nao sei ao certo,
mas acho que era apartir do nivel de complexidade do polimorfismo;
Complexidade do polimorfismo é para quem o usa. Para os novatos é muito complexo, mas os experientes nem se lembram que o estão usando.
|
|
|
|
camila_perusin wrote:Oiee pessoal.. será que alguem pode me ajudar?
Estou com este codigo abaixo, onde tenho definido tres tipos de valores:
Preco_horario até aas 14 horas
Preço Meia até as 18 horas
e preço intera acima das 18 horas
Porem estou com um probleminha.... qdo é 14:30 ele pega o preco do horario e nao o da meia...
O que estou fazendo de errado??
Vc está apenas comparando o campo de hora. vc precisa comparar tb os minutos
|
|
|
|
Isso significa que a classe que implementar o método não é obrigado a fazer aquilo que o método foi desenhado para fazer. Nesse caso ele deve lançar uma UnsupportedOperationException(). Nota: não significa que o método deve ter implementação vazia, e sim que ele deve lançar uma exceção informando que não suporta o uso daquele método.
Exemplo: Uma coleção não é obrigada a implementar add() e as coleções obtidas com Collections.singletonXXX ou Collections.emptyXXX realmente não implementam esse método (aliás , não faz sentido se implementassem).
O objetivo disse é criar coleções iteráveis, mas imutaveis.
Recentemente foi adicionada a interface Iteratable que simplifica o uso de coleções (e outras coisas) não obrigando o programador a usar coleções "parcilamente implementadas"
|
|
|
|
fabricioff wrote:Caros, dando uma olhada em exemplos me deparei com o código abaixo, ele se utiliza de um ImageIcon pra desenhar um buffer, isto está correto e se não estiver quais seriam outras formas de se fazer a mesma coisa, preciso fazer algo parecido mas estou tendo dificuldades com o SWING
Na realidade é ao contrário. Ele se utiliza de um buffer para criar um icon.
É correto sim. BufferedImage é o objeto a usar para criar imagens dinamicamente.
|
|
|
|
javaAurelio wrote:
Bom Dia
Um dia na aula de java o professor falo sobre niveis de polimorfismo, fique em duvida se existe mesmo.
Existe niveis de polimorfismo?
Obreigado
Podemos considerar que existem dois niveis de polimorfismo, embora não sei se era isso que o teu prof se estava a referir.
O polimorfismo estático e o dinânmico.
O estático compreende as capacidade de overload de métodos , shadowing se variáveis , autoboxing, generics e var args.
O dinâmico compreender as capacidade de overriding de metodos e possibilidade de manipular objetos usando suas interfaces ou classe abstrata.
Não é comum dividir o polimorfismo desta forma, então suponho que o teu prof estava falando de ter duas formas de criar polimorfismo de classes: classes abstratas e interfaces.
|
|
|
|
camilolopes wrote:ae pessoal da 1.4 e 1.5 houve updates bastante visiveis... mais da 1.5 para 1.6? qual a diferença entre usar a 1.5 e 1.6?
A nova politica da sun funciona assim:
As versões impares como o 5 trazem mudanças substanciais na linguagem java de programação. Tivemos o autoboxing , var args e os generics, por exemplo. E mudanças pequenas nas API.
as versões pares como a 6 trazem mudanças apenas nas API. Tivemos a API para inclusão de scripting, a API de desktop, por exemplo.
A versão 7 trará novas mudanças na linguagem. Ainda se especula quais e como, mas closures parece ser uma delas.
Esta regra só vale a partir da versão 5. (que mudou a nomenclatura das versões tb. Agoraé 5 ,6 e não mais 1.5 ou 1.6. E é JSE e JEE e JME e não mais J2SE , J2EE e JME)
|
|
|
|
pcalcado wrote:Ai ai ai...
Continuo sem ver onde naqueles texto está escrito que JavaBeans é uma especificação ultrapassada/morta/obsuleta etc... Tb não vejo onde diz lá que componentes swing não são javabeans nem onde diz que o netbeans não é baseado em javabeans.
Mas se realmente é verdade isso, então qual é o modelo de componentes do java usado pelo netbeans ?
|
|
|
|
jack_-_ganzha wrote:
Problema: adicione sete dias a um objeto Date e imprimir no formato dd/MM/yyyy.
Solução atual (escrevi direto no forum, mas é por ai):
Algum motivo especial para um problema tão simples exigir tanto código? Que tal assim:
Na realidade o codigo necessário é apenas
Motivos especiais:
Separação de Responsabilidade.
Internacionalização.
|
|
|
|
louds wrote:
sergiotaborda wrote:
O detalhe importante é que um javabean não é algo que tem get/set, é algo que lança eventos quando o seu estado muda (ou seja, todos os set lançam eventos). É isso que diferencia um JavaBean de um POJO
No caso da tua definição, nenhum dos componentes do Swing são javabeans, porque eventos e setter não estão atrelados.
Suponho que "atrelados" significa ter listeners registrados.
Ninguem disse que tinham que ter (embora esteja subentendido que tem que ter uma forma de os registrar.. ). Eu falei em lançar o evento, não se falou em capturar esse evento pq ,1) é dificil capturar sem lançar primeiro,2) a captura é responsabilidade de outro objecto que ninguem exige que seja um JavaBean)
Uma propertie não precisa suportar notificação, assim como um evento não precisa estar associado somente a propriedades.
Não precisa. Mas precisa para manter o padrão.
É como ter um construtor sem argumentos. Tem que ter para manter o padrão, mas não tem-que-ter-ou-o-mundo-vai-acabar tem-que-ter
Se vc não quer que tenha, ninguem o obriga.
Fora isso, a forma como era usada em 98, quando o JBF foi criado já morreu, é uma especificação morta, são conceitos mortos. Você pode continuar pensando em 98, mas não reclame quando as pessoas te acharem estranho por não usar o entendimento contemporâneo destes conceitos.
Ninguem perguntou se era viva, apenas se perguntou o que era.
Ao menos agora o colega que perguntou sabe que é/era uma especificação.
Mas é bom saber que ninguem use a o pacote java.beans que os componentes swing não lançam java.beans.PropertyChangeEvent quando as suas propriedades são alteradas. 
E a pergunta que não quer calar é  : se o objecto lança um evento e ninguem está lá para o ouvir, será que o evento foi mesmo lançado ?
|
|
|
|
Vc é muito engraçado.  Citar a specificação do java EE 1.3 .... não tem nada mais recente ? Algo que se possa aceitar que é atual ? ... talvez http://java.sun.com/j2se/1.5.0/docs/guide/beans/index.html
A "comunidade"já estragou o conceito... certo ainda bem que eu não faço parte dela ... ela vai ficar muito triste quando souber que o NetBeans funciona com base em JavaBeans. É tão importante que vc pode colocar os seus proprios http://www.cin.ufpe.br/~phmb/ip/MaterialDeEnsino/JavaBeans/RoteiroJavaBeansEclipse3/rot_NetBeans.html
... parece que continuam "dando murro em ponta de faca"
|
|
|
|
mwada wrote:Olá,
necessito criar uma aplicação no qual uma servlet realiza diversas buscas paralelamente e retorna a que veio mais rápido. Para isso, cogitei em utilizar ExecutorService e FutureTask do java.util.concurrent.
Alguém já utilizou essa API em Servlets? Essa abordagem pode gerar problemas por estar lidando com uma servlet gerenciando threads? Existe uma solução mais viável?
Abraços.
Com servlets nunca utilizei (aliás a especificação de servlet proibe de fazer isso ... mas... ) e realmente pode dar problemas se vc não fizer um join da thred corrente com as threads executoras. E não sei se tem como fazer isso no ExecutorService . Em opção vc pode implementar threads que façam o serviço e sincronizá-las manualmente com a thread executora do servlet.
|
|
|
|
pcalcado wrote:
Sérgio,
Em teoria eu concordo com você mas não existe mais o conceito de javaBeans há anos. Se quem criou a especificação foi a primeira a chamar classes com get/set de bean não há o que discutir.
Conceitos não deixam de existir... isso é anacrónico.
Podem deixar de ser usados, ou evoluir, mas não deixam de existir.
JavaBeans é umas especificação. Todos os componentes Swing são JavaBeans (não deixou de ser usado). O cara perguntou o conceito. O conceito é isso ai que está no link.
O detalhe importante é que um javabean não é algo que tem get/set, é algo que lança eventos quando o seu estado muda (ou seja, todos os set lançam eventos). É isso que diferencia um JavaBean de um POJO
|
|
|
|
adolfo_eloy wrote:Olá Pessoal.
Tenho uma dúvida a respeito da modelagem das classes,
Map, AbstractMap e HashMap.
Conforme a documentação da Sun que encontrei (api jse1.5),
Map é uma interface, onde as Classes AbstractMap e HashMap, a implementam.
Porém, além de HashMap implementar Map, a classe HashMap também
faz extensão da classe AbstractMap (que tbem implementa Map).
Qual a vantagem desta estrutura? Porque desta estrutura?
Porque HashMap não herda AbstractMap apenas, e o método que quiser
implementar, não sobrescreve?
HashMap implementa Map porque herda de AbstractMap que implementa Map. A razão disto é o design pattern Template Method. AbstractMap implementa todo o codigo reutilizável entre os diversos Map. Cada um depois so muda o que lhe interessa.
|
|
|
|