Existem vários exemplos onde os programadores utilizam o JComponent como nesse exemplo a seguir:
publicclassmodeloTabCellEditorextendsAbstractCellEditorimplementsTableCellEditor{JComponentcomponent=newJTextField();publicObjectgetCellEditorValue(){return((JTextField)component).getText();}publicComponentgetTableCellEditorComponent(JTabletable,Objectvalue,booleanisSelected,introw,intcolumn){if(isSelected){((JTextField)component).setBorder(BorderFactory.createBevelBorder(BevelBorder.LOWERED));}// Configure the component with the specified value((JTextField)component).setText(value.toString());// Return the configured componentreturncomponent;}}
Qual a vantagem nesse caso em declarar component como um JComponent e não como um JTextField?
Ao usar JTextField você “amarra” seu código a uma classe muito específica. Às vezes o componente editor de uma coluna de uma JTable não é um JTextField - poderia ser um seletor de cor, por exemplo. Então, é mais adequado usar a classe básica JComponent.
M
miguel.satriani
Vantagem nenhuma… Os metodos só retornam um Component para padronizar, pois se voce for ver os componentes swing são extensões do JComponent…
R
roger_rf
miguel: esse é justamente o objetivo do uso de Component/JComponent - definir uma classe básica. JComponent herda de Component para manter a compatibilidade com AWT, e Swing oferece JComponent para prover uma raiz comum aos criadores de componentes. Se o método getTableCellEditorComponent() da interface TableCellEditor retornasse um JTextField em vez de um Component, isso limitaria muito a liberdade do desenvolvedor - como eu faria quando quisesse retornar uma JComboBox? Então, considero que é, sim, uma vantagem.
homisinho
Muito obrigado pelas respostas.
Realmente essa é uma boa prática.
L
Leo_Luz
Não seria mais fácil colocar o Component somente no retorno no método “getTableCellEditorComponent” e tratar em todo o resto como um JTextField, já que o cara tá colocando explicitamente um “new JTextField()”?
Isso manteria a generalização do Component e evitaria os maltidos casts que tão rolando solto nessa implementação.
R
roger_rf
Leo: de acordo. Como nessa situação específica o método retorna sempre um JTextField, melhor declarar diretamente como JTextField e evitar os casts.
jidlafe
Olá homisinho, não esqueça também que o Java é uma linguagem
“escalável” e robusta. E que o OOD faz parte de toda a API da linguagem.
Se olhares na hierarquia de classes “swing” a JTextField é uma extensão de JTextComponent
que por sua vez é uma extensão de JComponent
Sendo assim o princípio de Polimorfismo é aplicado de forma correta. Pois você tem uma classe mais genêrica que comporta as
classes mais específicas a baixo na hierarquia.
