| Autor |
Mensagem |
|
|
leandroqbs wrote:E dividir demais complica tudo. Os desenvolvedores Java querem dividir tudo o máximo possível, querendo utilizar ao máximo o conceito de OO, mas se pararmos pra pensar, só faz sentido se isolado o que pode ser utilizado por outras classe, se for uma coisa única, deixe onde está... penso sempre na reutilização do código e não em firular demais a aplicação.
Rapaz... a idéia não é mesmo firular e sim deixar o código mais claro e limpo. Especialmente se você tem uma inicialização complexa. É muito mais fácil ler algo como:
x = integral(y);
Do que se eu colocasse o cálculo para calcular a integral diretamente no construtor...
Já leu Refatoração, do Martin Fowler? Ele explica exatamente esse conceito, o porque usar, como usar e para que usar. E mostra claramente a importância de usar métodos curtos, que podem te ajudar até a aumentar a performance de sua aplicação!
Dê uma conferida!! 
|
 |
|
|
O que estou dizendo é: não transforme seu objeto em String. Não tem porque você fazer isso, só vai complicar o seu código.
Claro que é possível recortar sua String. Mas insisto para que você leia acima como usar a lista para trabalhar com objeto diretamente. É muito mais fácil. Você está esquecendo de fazer o cast do seu objeto para o tipo original, por isso não consegue usar os métodos dele.
Por exemplo:
Se fizermos agora:
Isso não vai funcionar. O java dirá que a classe object não tem o método intValue (embora a classe integer tenha). Como arrumamos o código para que funcione?
Primeiro, temos que fazer um cast:
Agora, se você ainda insistir em recortar seu objeto:
Você tem a String
A variável exemplo agora deve valer:
"campo1=xyz, campo2=xyz, campo3=xyz"
A variável exemplo agora vale:
campo1=xyz=campo2=xyz=campo3=xyz
Agora, você tem um vetor contendo:
{"campo1", "xyz", "campo2", "xyz", "campo3", "xyz"}
Agora trabalhe com esse vetor. Note que você terá que mexer nesse código sempre que alterar o objeto, seja incluindo um campo ou alterando seu tipo.
E TUDO ISSO pode ser eliminado se você usar a lista com o objeto direto, e não com a String dele.
|
|
|
|
Poderia ser feito sim. E, no caso do JFrame, não há muito prejuízo em fazer isso.
Dá uma lida nesse tópico onde eu explico em detalhes quando e, principalmente, para quê usar a declaração do jeito que você fez originalmente.
|
|
|
|
O método execute retorna true se a consulta gerou um result set, o que não é o caso quando você tem um UPDATE.
Use o método executeUpdate, similar ao execute, mas que te retornará o número de registros afetados por sua consulta.
Não custa nada dar uma lida no Javadoc passado pelo colega, também.
|
|
|
|
Vão aí mais algumas dicas:
1. A classe bola não precisa ser um JFrame. Faça apenas um objeto comum, com um método draw, que recebe um Graphics2D. Chame esse método durante o paintComponent do frame principal, passando o objeto graphics do próprio frame principal (como demonstrado no próximo item);
2. Conforme indica o Javadoc, você não deve alterar o estado do objeto Graphics. Até para deixar a programação mais simples, no início de cada método de pintura (paintComponent ou draw) faça uma cópia do seu objeto Graphics assim:
3. É importante que você tenha um bom gameloop, é a alma do seu jogo. O game loop é a thread que controla o fluxo do seu jogo. Há duas maneiras de se controlar esse fluxo. A primeira é manter a taxa de updates por segundo e frames por segundo a mais rápida possível e fazer todos os deslocamentos de objetos no jogo baseados numa diferença de tempos entre dois passos. Embora o algoritmo do loop fique mais simples, essa forma gera um código mais complexo no resto do jogo.
A segunda forma, que descrevo nesse artigo em que baseei no killer, é mantendo a taxa de frames alta, porém a taxa de updates constante. Não é necessário saber diferenças de tempo para atualização de movimentos, pois essa diferença será sempre a mesma.
4. Baixe o Vikanoid e preste atenção especialmente nas classes Bat e Ball (muito similares a sua). Depois, dê no pacote JGF, dê uma olhada nas classes que controlam a thread principal e na classe ScreenManager. O código está bem documentado (pros padrões que a gente vê por aí), mas está todo em inglês (pelo menos, espero que aquilo seja um bom inglês  ) mas qualquer coisa, pode me perguntar que eu te explico!
5. Depois de pronto, deixe o jogo com os fontes no GUJ pra gente se divertir! E pra mais gente como você e eu trocarmos mais idéias!
|
|
|
|
É o seguinte... em primeiro lugar, não sobrescreva o paint diretamente, sobrescreva paintComponent no lugar. O método paint faz chamada a paintComponent, paintBorder e paintChildren.
Depois, nem sempre que você chamar repaint o paint será ativado. A AWT tem o direito de fazer uma coisa chamada "event coalescing", ou seja, ignorar alguns repaints para ganhar um pouco de performance. Embora isso seja bom para a maior parte dos aplicativos swing, jogos são uma exceção a regra. É necessário usar pintura direta.
Já que você quer implementar um jogo, eu recomendo que você leia os primeiros capítulos do livro Killer Game Programming in Java, que podem ser baixados diretamente do site oficial. Ele explica como implementar a pintura direta, colocar o jogo em full screen e trabalhar com imagens e som. É uma ótima literatura. Se você estiver disposto a investir em livros desse gênero, dá uma olhada também em Developing Games in Java, do Dave Brackeen. A parte de áudio desse outro livro é simplesmente sensacional.
Eu também implementei um jogo similar ao que você está fazendo e que você pode fazer o download (com os fontes e tudo mais) aqui.
|
|
|
|
Você pode implementar uma classe só e usar generics.
E depois, na hora de usar:
Para mais informações leia o Generics Tutorial, da própria sun.
|
|
|
|
Você pode colocar num List.
Existem duas formas de usar o list. A primeira é antes do Java 5.
Tempos depois, na hora de usar o objeto dentro da lista:
Você deve ter esquecido o cast.
E tem a forma após o Java 5, onde você pode dizer o tipo de objeto que vai dentro da lista.
Tempos depois, na hora de o objeto dentro da lista:
O jeito que você está fazendo, de tentar dividir o resultado do toString() é desnecessariamente trabalhoso e muito sujeito a erros.
|
|
|
|
leandroqbs wrote:Mas da próxima vez, tente não utilizar essa solução, da pra fazer o que quiser em Java sem precisar utilizar o construtor pra carregar outros métodos... não fica muito bonito...
Pq não fica bonito? Respeitando a regra de que os métodos devem ser private ou final, não vejo porque não utilizar. Dividir em outros métodos geralmente deixa o código mais organizado.
|
|
|
|
Não sei como o eclipse faz...
Mas uma ferramenta para análise de textos, usada em compiladores e que pode te ajudar é o antlr. Mas para usa-lo, você terá que lembrar das suas aulas de compiladores e lembrar de como se faz uma gramática.
É MUITO mais fácil do que tentar entender o texto na mão.
Uma outra forma mais simples é analisar o conteúdo da linha do cursor e gerar os getters e setters sobre aquela linha. O único problema nesse caso é que você poderá gerar gets e sets duplicados.
|
|
|
|
É sim. Pode chamar outros métodos normalmente.
Mas tome o cuidado para que esses métodos sejam ou private, ou final. Senão uma subclasse poderá sobrescreve-lo e alterar o comportamento esperado.
Lembre-se que o objeto é construído a partir da super-classe, então, chamar um método sobrescrito no construtor pode recair no sério problema da subclasse tentar usar um atributo que ainda não foi inicializado!!!
|
|
|
|
Definições absolutas não são uma boa alternativa pois:
1. Elas não tornam sua tela redimensionavel;
2. Elas não funcionam em ambientes multi-plataforma.
Como o colega ressaltou, dê uma pesquisada projeto Matisse do Netbeans ou no Visual Editor do Eclipse. Eles te permitem editar as telas visualmente, de maneira fácil.
O LayoutManager que eu geralmente uso é o GridBagLayout. Geralmente faço as telas no Visual Editor, mas estou seriamente pensando em ir pro Matisse. É só o tempo do Netbeans ter um editor de código tão ou mais poderoso que o o do Eclipse...
|
|
|
|
E o pessoal que duplica, triplica, quadruplica tópicos?
E isso muitas vezes acontece, mesmo com o tópico original respondido!
Não sei o que esse tipo de pessoa quer, mas acho que também é na linha do suporte técnico grátis.
Também sinto falto do agredecimento. Não tanto pelo agrecimento em si, mas para saber se o cara realmente resolveu o problema, ou se não entendeu patavinas do que foi dito.
|
|
|
|
Você pode fazer o seu próprio console. Para isso, crie uma classe gerenciadora que manipule um JTextArea. Você precisará capturar eventos de mouse e teclado.
É possível também conectar-se ao próprio console do DOS, mas daí você não terá recursos como cores, pois os dados dele serão exibidos num JTextArea, da mesma forma.
Você não pode usar o Swing e fazer uma interface gráfica?
|
|
|
|
O que você quer?
O programa pronto?
Grosseria não vai te ajudar. Estou te orientando sobre como utilizar o fórum. Se você tem um problema e criou um tópico, cabe a você acompanha-lo e dar continuidade ao assunto.
O pessoal começou a te "dar idéias" nesse tópico, mas parece que as respostas não serviram.
Você tentou usar alguma das APIs sugeridas? Ou não era bem aquilo que você queria? Por que deu errado? Por que existe a necessidade de uma interface estilo console e não pode ser algo visual?
São coisas que você já deveria ter respondido, no seu tópico original. Ele voltará automaticamente a lista dos tópicos recentes, que é acompanhada por boa parte do pessoal do fórum. Todos que um dia contribuiram por lá ou que marcaram o tópico para acompanhamento receberão um e-mail, muitos irão revisitar o assunto imediatamente.
|
|
|
|
|
|