Yocker
  1. Yocker
  3. Estende JFrame e creandolo all’interno del programma
Intereting Posts
Immagine / grafica in una forma Come contare gli elementi nella lista separata da virgola MySQL Usa String.split () con delimitatori multipli OpenGL 2 Texture Formati interni GL_RGB8I, GL_RGB32UI, ecc Caricamento di immagini tramite Node.js, Express e Mongoose jQuery se la casella è selezionata Problema di codifica dei caratteri JSoup Qual è l’equivalente Git per il numero di revisione? Costruire glew su windows con mingw Modo moderno per impostare i flag del compilatore nel progetto cmake multipiattaforma MySQL – Design Supertype / Sottotipo java.lang.IllegalStateException: il percorso dell’eseguibile del driver deve essere impostato dalla proprietà di sistema webdriver.chrome.driver Intervallo del valore di ritorno della funzione principale Come garantire che tutti i dati siano stati scritti fisicamente sul disco? homebrew non funziona su OSX

Estende JFrame e creandolo all’interno del programma

Quando faccio un’applicazione con Swing, ho visto persone fare una delle due cose per creare una JFrame. Qual è un approccio migliore e perché?

Sono un principiante in Java e in programmazione. La mia unica fonte di apprendimento è libri, YouTube e Stack Overflow. 

import {imports}; public class GuiApp1 { public static void main(String[] args) { new GuiApp1(); } public GuiApp1() { JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250); ................ }

E 

 import {imports}; public class GuiApp1 extends JFrame { public Execute() { getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600); ............. } public static void main(String[] args) { Execute frame1 = new Execute(); frame1.setVisible(true); } }

Pensieri:

  • Evita di estendere JFrame poiché lega la tua GUI all’essere, beh, un JFrame. Se invece ti concentri invece sulla creazione di JPanel, allora hai la libertà di usare questi JPanel ovunque sia necessario – in un JFrame, o JDialog, o JApplet, o all’interno di un altro JPanel, o scambiati con altri JPanel tramite un CardLayout.
  • Evita l’ereditarietà in generale, specialmente di classi complesse. Ciò eviterà errori dannosi, come l’annullamento involontario dei metodi (prova a creare un JFrame o JPanel che abbia un getX() e getY() per vedere cosa intendo!).
  • Evitare l’ereditarietà di classi complesse se si utilizza un IDE: se si esegue l’override di una class complessa, quando si chiamano metodi su oggetti di queste classi, si avranno a disposizione troppe opzioni di metodi.
  • L’incapsulamento è buono, è e consente la creazione di codice più sicuro. Esporre solo ciò che deve essere esposto e controllare l’esposizione il più ansible.

Preferisci la composizione rispetto all’ereditarietà .

Il secondo esempio utilizza l’ereditarietà, ma senza una buona ragione, dal momento che non modifica la funzionalità di JFrame .

Per inciso, se questi sono esempi di codice che stai vedendo, trova una nuova fonte supplementare . Anche nelle poche righe di codice mostrate, ognuna fa cose altamente discutibili. PER ESEMPIO

  1. Né la GUI viene creata nel thread di invio eventi.
  2. getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600);
    • La prima parte della prima riga ( getContentPane() ) non è stata necessaria da Java 1.5
    • La seconda riga usa un layout null , che si spezzerà in più modi che posso contare o descrivere.
    • La terza riga dovrebbe essere sostituita al meglio con pack();
  3. JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250);
    • La prima e la terza riga potrebbero essere contratte per:
      JFrame guiFrame = new JFrame("Example GUI");
    • La seconda linea è meglio impostata su guiFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    • La terza riga imposta nuovamente una dimensione al fotogramma.

Supplemento

  1. Dopo aver menzionato fai una ricerca SO, ecco un suggerimento. Consulta i post dei primi 15 fornitori di risposte negli utenti migliori di Swing . Qualunque consiglio / codice che spigoli da queste persone, commetterebbe pochi se nessuno degli errori in quei campioni di codice.

    Alcuni spesso non forniscono (o mai) esempi autonomi come fanno alcuni di noi (e non considerano tali esempi necessariamente per il design OO in opposizione alla sola tecnica), ma qualunque sia il codice che forniscono, o il consiglio che danno , dovrebbe essere altamente considerato.

Personalmente, il primo approccio (creare un’istanza di JFrame ) è preferito, preferisco questo perché …

Non blocca la tua applicazione in un contenitore dedicato … vedi molte persone che vogliono aggiungere applet a frame e frame alle applet, se avessero messo la maggior parte della GUI in un JPanel per iniziare, non avrebbero avere questi problemi

Significa anche che l’interfaccia utente che crei è molto più flessibile. Ad esempio, puoi riutilizzarlo, sia nell’applicazione corrente che nelle applicazioni future, non ti blocchi.

Il problema principale che ho con l’estensione di JFrame è che in realtà non stai aggiungendo nuove funzionalità o funzionalità, che potrebbero essere riutilizzate in modo efficace oltre l’utilizzo di setVisible

L’altro problema che ho con l’estensione di JFrame è che le persone sovrascrivono prontamente la paint , il che è davvero molto brutto. Ci sono così tanti problemi nel fare ciò che è semplicemente doloroso doverli elencare ripetutamente …

Quindi … per più di 2 centesimi. Crea un’istanza di JFrame e aggiungi il tuo contenuto. Se necessario, crea un metodo static chiama showMyAwesomeGUI che lo fa per te …

Il primo approccio è migliore.

In genere non si aggiungono nuove funzionalità al frame, quindi è consigliabile creare un’istanza diretta della class.

Vai per il primo approccio.

Perché con quello puoi avere più fotogrammi da creare. Perché l’applicazione può avere più di una finestra. Come nel secondo caso non puoi creare più fotogrammi.

Non importa.

Ci sono dei motivi per cui potresti fare l’uno o l’altro, ma in assenza di questi motivi non fa alcuna differenza.

Ora, se scrivessi qualcosa che potrebbe funzionare dalla riga di comando o potrebbe essere un programma GUI, ovviamente potresti volere una class ‘principale’ che non fosse una class GUI.

Se hai lavorato in un negozio di programmazione in cui uno o l’altro era lo standard, segui assolutamente lo standard. Non c’è una risposta giusta a questo, e in effetti molto poco da scegliere tra loro.