Alcuni chiarimenti sul modello di adattatore applicato agli eventi Swing in Java


Sto studiando lo swing Java e come gestire un evento usando il pattern adapter per non eseguire l'override di tutti i metodi che gestiscono un evento.

Ho trovato questo breve esempio e voglio sapere se l'ho capito:

import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JFrame;

public class Sketcher {
    JFrame window = new JFrame("Sketcher");

    public Sketcher() {
        window.setBounds(30, 30, 300, 300);
        window.addWindowListener(new WindowHandler());
        window.setVisible(true);
    }

    class WindowHandler extends WindowAdapter {
        public void windowClosing(WindowEvent e) {
            System.out.println("closing");
            window.dispose(); // Release the window resources
            System.exit(0); // End the application
        }
    }

    public static void main(String[] args) {
        new Sketcher();
    }
}

Quello che ho capito è:

La classe Sketcher contiene un metodo principale che crea semplicemente una nuova istanza di Sketcher.

Un'istanza Sketcher crea un nuovo oggetto JFrame che mostra semplicemente un fotogramma su monitor.

Quindi quando creo un nuovo oggetto Sketcher viene creato un nuovo oggetto JFrame.

E qui ho il mio primo dubbio, che un dubbio di Java di generi,:

Perché non sto creando l'oggetto Jframe windos all'interno del costruttore della classe Sketcher?

Qualunque cosa, nel costruttore, ho impostato alcune proprietà per l'oggetto JFrame e aggiungo un WindowListener a questo JFrame.

Ora addWindowListener è un nuovo oggetto WindowHandler che è un'abitudine oggetto che gestisce gli eventi di Windows.

Ora ho due possibilità per gestire questi eventi:

  1. Usa il classico Listener : in questo caso devo implementare un listener specifico per TUTTI i possibili eventi che possono verificarsi sul JFrame

  2. Usa un adattatore (come in questo caso), quindi in questo caso uso una classe interna chiamata WindowHandler che estende la classe WindowAdapter . La classe WindowAdapter contiene metodi void per tutti gli eventi Jframe possibili. Quindi nel WindowHandler posso definire SOLO il metodo che voglio gestire e non tutti i metodi.

È giusto il mio ragionamento? È un buon esempio di tutorial o presenta qualche problema che ora non riesco a vedere?

Tnx

Andrea

Author: AndreaNobili, 2013-09-24

1 answers

Il tuo ragionamento è corretto, ma ecco alcune note:

  1. Hai posto la domanda Perché non sto creando l'oggetto JFrame windows all'interno del costruttore della classe Sketcher?

    Il compilatore sta facendo un po ' di lavoro per te; in realtà posiziona l'inizializzazione del JFrame all'interno del tuo costruttore. È inoltre possibile inserire esplicitamente l'inizializzazione JFrame nel costruttore.

  2. La tua WindowHandler classe non ha per essere un interno classe; potrebbe essere qualsiasi classe che implementa WindowListener o estende WindowAdapter.

  3. Le classi XXXAdapter in AWT e Swing sono solo una convenzione di denominazione per le classi che forniscono implementazioni di convenienza senza operazioni dell'interfaccia correlata. Non sono realmente adattatori (vedi sotto).

  4. La tua implementazione main non ha per essere nella classe del tuo frame; potrebbe essere in qualsiasi classe.

In generale, non ci piace creare un sacco di cose all'interno un costruttore, specialmente se potrebbero esserci effetti collaterali. È meglio fornire metodi di costruzione e inizializzazione separati.

In particolare per Swing, è tipico sottoclasse i componenti per fornire la specializzazione dell'interfaccia utente necessaria per l'applicazione, inclusi i JFrames. Ma mantenere la logica di business separata.

Anche se la classe swing si chiama WindowAdapter, in realtà non sta adattando nulla nel senso del modello dell'adattatore. Ciò che fornisce è un valore predefinito implementazione senza operazioni di tutti i metodi dell'interfaccia WindowListener, che consente a uno sviluppatore di sovrascrivere solo il metodo a cui è interessato.

Quindi direi che questo è più uno studio di overriding che un adattamento; quest'ultimo è solitamente usato per far funzionare due API incompatibili insieme .

 1
Author: WeaponsGrade, 2013-09-24 16:02:27