Quelques clarifications sur le modèle d'adaptateur appliqué aux événements Swing en Java


J'étudie le swing Java et comment gérer un événement en utilisant le modèle d'adaptateur pour ne pas remplacer toutes les méthodes qui gèrent un événement.

J'ai trouvé ce court exemple et je veux savoir si je l'ai compris:

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();
    }
}

Ce que j'ai compris, c'est:

La classe Sketcher contient une méthode principale qui crée simplement une nouvelle instance Sketcher.

Une instance Sketcher crée un nouvel objet JFrame qui affiche simplement un cadre sur surveiller.

Donc, lorsque je crée un nouvel objet Sketcher, un nouvel objet JFrame est créé.

Et ici j'ai mon premier doute (c'est un doute genera Java):

Pourquoi je ne crée pas l'objet JFrame windos dans le constructeur de la classe Sketcher?

Quoi qu'il en soit, dans le constructeur, j'ai défini une propriété pour l'objet JFrame et j'ajoute un WindowListener à ce JFrame.

Maintenant l'addWindowListener est une nouvelle WindowHandler objet personnalisé objet qui gère les événements Windows.

Maintenant, j'ai deux possibilités pour gérer ces événements:

  1. Utilisez les classic Listeners : dans ce cas, je dois implémenter un listener spécifique pour TOUS les événements possibles qui peuvent se produire sur le JFrame

  2. Utiliser un adaptateur (comme dans ce cas), donc dans ce cas je utiliser une classe interne nommé WindowHandler, ce qui étend la classe WindowAdapter. La classe WindowAdapter contient des méthodes void pour tous les événements JFrame possibles. Donc, dans le WindowHandler je ne peux définir QUE la méthode que je veux gérer et pas toutes les méthodes.

Est-ce bien mon raisonnement? Est-ce un bon exemple de tutoriel ou il présente un problème que maintenant je ne peux pas voir?

Tnx

Andrea

Author: AndreaNobili, 2013-09-24

1 answers

Votre raisonnement est correct, mais voici quelques remarques:

  1. Vous avez posé la question Pourquoi ne suis-je pas en train de créer l'objet windows JFrame dans le constructeur de la classe Sketcher?

    Le compilateur fait du travail pour vous; il place en fait l'initialisation du JFrame dans votre constructeur. Vous pouvez également placer explicitement l'initialisation JFrame dans votre constructeur.

  2. Votre classe WindowHandler n'a pas {[14] } pour être une classe interne classe; ce pourrait être n'importe quelle classe qui implémente WindowListener ou étend WindowAdapter.

  3. Les classes XXXAdapter dans AWT et Swing sont juste une convention de nommage pour les classes qui fournissent des implémentations de commodité sans opération de l'interface associée. Ce ne sont pas vraiment des adaptateurs (voir ci-dessous).

  4. Votre implémentation main n'a pas à être dans la classe de votre cadre; elle pourrait être dans n'importe quelle classe.

Généralement, nous n'aimons pas créer un tas de choses à l'intérieur un constructeur, surtout s'il pourrait y avoir des effets secondaires. Il est préférable de fournir des méthodes de construction et d'initialisation distinctes.

Spécifiquement pour Swing, il est typique de sous-classer les composants pour fournir la spécialisation de l'interface utilisateur nécessaire à votre application, y compris les JFrames. Mais gardez la logique métier séparée.

Même si la classe swing est nommée WindowAdapter, elle n'adapte vraiment rien au sens du modèle d'adaptateur. Ce qu'il fournit est une valeur par défaut implémentation sans opération de toutes les méthodes de l'interface WindowListener, ce qui permet à un développeur de remplacer uniquement la méthode qui l'intéresse.

Donc je dirais que c'est plus une étude de overridingqu'une adaptation; cette dernière est généralement utilisée pour faire fonctionner deux API incompatibles.

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