2012-05-04 8 views
8

Quali sono i pro e i contro di estendere un JFrame anziché creare un nuovo JFrame?Estensione di un JFrame

Ad esempio:

public class Test extends JFrame { 

setVisible(true); 

} 

o

public class Test { 

JFrame test = new JFrame(): 

test.setVisible(true); 

} 

risposta

9

Non si deve estendere una classe, a meno che non si desidera estendere in realtà la sua funzionalità, nell'esempio avete dimostrato, si dovrebbe utilizzare l'opzione 2, in quanto l'opzione 1 è un abuso della funzione extend.

In altre parole, a patto che la risposta alla domanda sia Test a JFrame? è NO, non deve essere esteso a JFrame.

+1

Amen, e d'accordo al 100% 1+ up-voto. –

+0

Se aggiungo alcuni metodi nella classe estesa, non sto estendendo il JFrame? Per favore, rispondi a questo. Perché l'opzione 1 è un abuso della funzione di estensione? Non stava ignorando un metodo chiamato setVisible. Significa che non posso chiamare metodi ereditati? Perché non finalizzare il JFrame esteso se preoccupato per potenziali sottoclassi? Non penso sia ** sbagliato ** estendere JFrame per creare una finestra, se è una finestra. –

+0

Sto cercando di capire meglio. Un esempio di scuola: uno studente estende una persona. Lo studente ha la possibilità di accedere, la persona no. Una finestra "NewTask" fornisce una funzione per creare una nuova attività in base a un modulo, JFrame no. –

8

pro di che non si estende JFrame (o qualsiasi componente Swing è per questo):

  • Evita metodo non intenzionali sostituzioni. Ci sono passato più volte, prima quando ho dato i miei metodi di classe int getX() e int getY(). Provalo e vedrai alcuni comportamenti anormali non così divertenti.
  • Semplifica le opzioni di metodo disponibili quando si utilizzano Eclipse o NetBeans solo per i metodi che sono stati creati. Questo è in realtà il mio vantaggio preferito.
  • Gearing your GUI per creare JPanels anziché JFrames che aumenta la flessibilità di implementazione 100 volte.
  • E, soprattutto, esponendo solo ciò che è necessario esporre.
+0

Mi piace il punto 3, quindi +1 per te. – Jasonw

+2

* "Gearing your GUI per creare JPanels piuttosto che JFrames .." * Certo, ma attenzione a non cadere nella stessa trappola di estendere il pannello (a meno che non si applichi il comportamento personalizzato della vernice ecc.). –

+1

Di gran lunga il punto 4 è il più importante secondo me. +1 –

0

Una delle regole di OOD: se non è possibile ereditare (estendere) le classi non ereditate le loro.

L'ereditarietà aumenta la complessità e la connettività del programma e potenzialmente può portare a nuovi errori. Nel tuo caso non ci sono ragioni per prolungare la lezione.

È necessario estendere le classi solo quando è necessario ottenere l'accesso ai membri protetti e/o ottenere un comportamento polimorfico (ignorare i metodi virtuali).

+0

* ".. le classi che non ereditate loro." * Loro cosa? Mi hai appeso alla prossima parola ..;) –

2

Se si estende JFrame, vorrei modificare/personalizzare la mia classe Jframe corrente e quindi la sottoclasse può utilizzare questa implementazione personalizzata.

Se non c'è niente che io voglio fare il cambiamento della classe JFrame, basta uso il esistente come nel secondo frammento che hai dato nel codice. Per uso, intendo creando un altro JComponent (pulsante/etichetta per esempi), ecc. In un JPanel e crea un oggetto Test e imposta JFrame contentPane su questo oggetto. Qualcosa di simile

public class Test extends JPanel { 

    public class() { 
    // add buttons/label here 
    } 
    ... 

    private static void createAndShowGUI() { 
     JFrame frame = new JFrame(); 

     Test object = new Test(); 
     frame.setContentPane(object.setOpaque(true)); 

     frame.setVisible(true); 
    } 
... 
}