| Penser en Java 2nde édition | - | Sommaire | Préface | Avant-propos | Chapitre : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Annexe : A B C D | Tables des matières | - | Thinking in Java |
Il est également possible de créer un package de look and feel sur mesure, par exemple si on crée un environnement de travail pour une société qui désire une apparence spéciale. C'est un gros travail qui est bien au-delà de la portée de ce livre (en fait vous découvrirez qu'il est au-delà de la portée de beaucoup de livres dédiés à Swing).name="_Toc481064830">
JFC permet des opérations limitées avec le presse-papier système (dans le package java.awt.datatransfer). On peut copier des objets String dans le presse-papier en tant que texte, et on peut coller du texte depuis le presse-papier dans des objets String. Bien sûr, le presse-papier est prévu pour contenir n'importe quel type de données, mais la représentation de ces données dans le presse-papier est du ressort du programme effectuant les opérations de couper et coller. L'API Java clipboard permet ces extensions à l'aide du concept de «parfum» [flavor]. Les données en provenance du presse-papier sont associées à un ensemble de flavorsdans lesquels on peut les convertir (par exemple, un graphe peut être représenté par une chaîne de nombres ou par une image) et on peut vérifier si les données contenues dans le presse-papier acceptent le flavor qui nous intéresse.
Le programme suivant est une démonstration simple de couper, copier et coller des données String dans une face="Georgia">JTextArea. On remarquera que les séquences clavier utilisées normalement pour couper, copier et coller fonctionnent également. Mais si on observe un JTextField ou un JTextArea dans tout autre programme, on verra qu'ils acceptent aussi automatiquement les séquences clavier du presse-papier. Cet exemple ajoute simplement un contrôle du presse-papier par le programme, et on peut utiliser ces techniques pour capturer du texte du presse-papier depuis autre chose qu'un JTextComponent.
La création et l'ajout du menu et du JTextArea devraient être maintenant une activité naturelle. Ce qui est différent est la création du champ Clipboard clipbd, qui est faite à l'aide du Toolkit.
Toutes les actions sont effectuées dans les listeners. Les listeners CopyL et CutL sont identiques à l'exception de la dernière ligne de CutL, qui efface la ligne qui a été copiée. Les deux lignes particulières sont la création d'un objet StringSelection à partir du String, et l'appel à setContents() avec ce StringSelection. C'est tout ce qu'il y a à faire pour mettre une String dans le presse-papier.
Dans PasteL, les données sont extraites du presse-papier à l'aide de name="Index1777">getContents(). Ce qu'il en sort est un objet Transferableassez anonyme, et on ne sait pas exactement ce qu'il contient. Un moyen de le savoir est d'appeler getTransferDataFlavors(), qui renvoie un tableau d'objets name="Index1780">DataFlavorindiquant quels flavors sont acceptés par cet objet. On peut aussi le demander directement à l'aide de isDataFlavorSupported(), en passant en paramètre le flavor qui nous intéresse. Dans ce programme, toutefois, on utilise une approche téméraire : on appelle getTransferData()en supposant que le contenu accepte le flavor String, et si ce n'est pas le cas le problème est pris en charge par le traitement d'exception.
Dans le futur, on peut s'attendre à ce qu'il y ait plus de flavors acceptés.
Une utilisation importante de l'utilitaire JAR est l'optimisation du chargement d'une applet. En Java 1.0, les gens avaient tendance à entasser tout leur code dans une seule classe, de sorte que le client ne devait faire qu'une seule requête au serveur pour télécharger le code de l'applet. Ceci avait pour résultat des programmes désordonnés, difficiles à lire (et à maintenir), et d'autre part le fichier .class n'était pas compressé, de sorte que le téléchargement n'était pas aussi rapide que possible.
Les fichiers JAR résolvent le problème en compressant tous les fichiers .class en un seul fichier qui est téléchargé par le navigateur. On peut maintenant avoir une conception correcte sans se préoccuper du nombre de fichiers .class qui seront nécessaires, et l'utilisateur aura un temps de téléchargement beaucoup plus court.
Prenons par exemple TicTacToe.java. Il apparaît comme une seule classe, mais en fait il contient cinq classes internes, ce qui fait six au total. Une fois le programme compilé on l'emballe dans un fichier JAR avec l'instruction :
Ceci suppose que dans le répertoire courant il n'y a que les fichiers .class issus de TicTacToe.java (sinon on emporte du bagage supplémentaire).
On peut maintenant créer une page HTML avec le nouveau tag name="Index1785">archive pour indiquer le nom du fichier JAR. Voici pour exemple le tag utilisant l'ancienne forme du tag HTML :
La programmation de GUI en Java étant une technologie évolutive, avec des modifications très importantes entre Java 1.0/1.1 et la bibliothèque Swing, certains styles de programmation anciens ont pu s'insinuer dans des exemples qu'on peut trouver pour Swing. D'autre part, Swing permet une meilleure programmation que ce que permettaient les anciens modèles. Dans cette partie, certains de ces problèmes vont être montrés en présentant et en examinant certains styles de programmation.
Un des avantages du modèle d'événements Swing est sa flexibilité. On peut ajouter ou retirer un comportement sur événement à l'aide d'un simple appel de méthode. L'exemple suivant le montre :
Les nouvelles astuces dans cet exemple sont :
Ce genre de flexibilité permet une grande puissance de programmation.
Il faut remarquer qu'il n'est pas garanti que les listeners d'événements soient appelés dans l'ordre dans lequel ils sont ajoutés (bien que la plupart des implémentations le fasse de cette façon).
En général on conçoit les classes de manière à ce que chacune fasse une seule chose. Ceci est particulièrement important pour le code d'une interface utilisateur, car il arrive souvent qu'on lie ce qu'on fait à la manière dont on l'affiche. Ce genre de couplage empêche la réutilisation du code. Il est de loin préférable de séparer la logique applicative de la partie GUI. De cette manière, non seulement la logique applicative est plus facile à réutiliser, mais il est également plus facile de récupérer la GUI.
Un autre problème concerne les systèmes répartis [multitiered systems], dans lesquels les objets applicatifs se trouvent sur une machine séparée. Cette centralisation des règles applicatives permet des modifications ayant un effet immédiat pour toutes les nouvelles transactions, ce qui est une façon intéressante d'installer un système. Cependant, ces objets applicatifs peuvent être utilisés dans de nombreuses applications, et de ce fait ils ne devraient pas être liés à un mode d'affichage particulier. Ils devraient se contenter d'effectuer les opérations applicatives, et rien de plus.
L'exemple suivant montre comme il est facile de séparer la logique applicative du code GUI :
On peut voir que BusinessLogic est une classe toute simple, qui effectue ses opérations sans même avoir idée qu'elle puisse être utilisée dans un environnement GUI. Elle se contente d'effectuer son travail.
Separationgarde la trace des détails de l'interface utilisateur, et elle communique avec BusinessLogic uniquement à travers son interface public. Toutes les opérations sont concentrées sur l'échange d'informations bidirectionnel entre l'interface utilisateur et l'objet BusinessLogic. De même, Separation fait uniquement son travail. Comme Separation sait uniquement qu'il parle à un objet BusinessLogic (c'est à dire qu'il n'est pas fortement couplé), il pourrait facilement être transformé pour parler à d'autres types d'objets.
Penser à séparer l'interface utilisateur de la logique applicative facilite également l'adaptation de code existant pour fonctionner avec Java.
Les classes internes, le modèle d'événements de Swing, et le fait que l'ancien modèle d'événements soit toujours disponible avec de nouvelles fonctionnalités des bibliothèques qui reposent sur l'ancien style de programmation, ont ajouté un nouvel élément de confusion dans le processus de conception du code. Il y a maintenant encore plus de façons d'écrire du mauvais code.
A l'exception de circonstances qui tendent à disparaître, on peut toujours utiliser l'approche la plus simple et la plus claire : les classes listener (normalement des classes internes) pour tous les besoins de traitement d'événements. C'est la forme utilisée dans la plupart des exemples de ce chapitre.
En suivant ce modèle on devrait pouvoir réduire les lignes de programmes qui disent : «Je me demande ce qui a provoqué cet événement». Chaque morceau de code doit se concentrer sur une action, et non pas sur des vérifications de types. C'est la meilleure manière d'écrire le code; c'est non seulement plus facile à conceptualiser, mais également beaucoup plus facile à lire et à maintenir.
