Qual desses dois é melhor?
Eles não são concorrentes…Um é default que ja faz coisas padrões…outro é abstract que deixa as coisas pendentes para vc especializar…
Tudo depende de onde vc esta e aonde vc quer chegar…
1 curtida
Sempre prefiro especializar um AbstractTableModel, pra implementar o modelo de forma mais eficiente que o DefaultTableModel.
Exemplo aqui.
Gostaria de aproveitar a perguntar dele, e fazer a minha: Sei que a pergunta dele é sobre o DefaultListModel, mas tem a ver com o Table… Se, o DefaultTableModel faz as mesmas coisas que o AbstractTableModel faz, então porque implementar e especializar de forma mais eficiente o que o outro já tem por padrão? Seria reinventar a roda, não?
O DefaultTableModel não faz as mesmas coisas que o AbstractTableModel.
AbstractTableModel é abstrato, então alguns métodos ele não implementa.
O DefaultTableModel permite que você fique adicionando itens a uma lista interna dele e, dessa forma, a maioria dos programadores começam a escrever código que é lento.
Quando você costuma realizar uma consulta em uma base de dados por exemplo, se você usar JPA, você já terá uma lista de objetos pronta então é perda de tempo você:
- remover os itens do DefaultTableModel;
- fazer um laço para pegar cada objeto seu;
- pra cada objeto criar um array de objetos e adicionar na lista do
DefaultTableModel.
É bem mais rápido você especializar o AbstractTableModel de forma a somente renderizar a lista de objetos já existentes.
Reescrever algo de forma mais eficiente não é reinventar a roda.
Ninguém põe uma roda de madeira, utilizada em carroças, em um carro.
É bem melhor colocar uma roda “reinventada” de borracha. 
1 curtida
Esta aí um cara que eu digo que soube me explicar o que muitos só enrolam para escrever. Obrigado @staroski Agora, para mim, faz sentido aprender mais sobre AbastractTableModel e o List também!
1 curtida
Esta discussão é tão antiga quanto o Swing no java…
Qual a razão em ter-se mantido a DefaultTableModel, sendo que existe a AbstractTableModel?
Você pode desenvolver um TCC sobre isso. Eu vejo da seguinte maneira: assim como na vida, em certos momentos, precisamos usar um martelo e, em outros, uma chave inglesa, a programação também é assim.
Desenvolvi minha monografia toda em Swing, um sistema de gerenciamento hospitalar. Por conta disso, havia muitas tabelas e eu era um sub noob (menos que new bee) em programação java.
Resultado? Ignorei a “complexidade” do AbstractTableModel e parti para o DefaultTableModel.
Lentidão? Sinceramente, num protótipo mal prototipado de sistema, imperceptível.
O que quero dizer é que, se o teu foco não é, efetivamente, customização e desempenho, vá de DefaultTableModel.
Agora, se por alguma razão, você precisa ter um sistema super rápido (e, conseguir constatar a diferença de desempenho com benchmarks precisos), vá de AbstractTableModel.
Do ponto de vista de desenvolvimento eu sempre opto pelo controle das coisas (ahá, pego no pulo, então você não usa CDI, Spring, inversão de controle, injeção de dependências, JPA e o escambau, @drsmachado? Isso é outro papo). Assim sendo, eu prefiro ter conhecimento do que está em execução, como o método vai se comportar e tudo mais. Assim sendo, mesmo para coisas simples e a AbstractTableModel (que, no fim das contas, acaba sendo muito mais simples que a DefaultTableModel)
2 curtidas