Serie 4 Genie Logiciel II
Serie 4 Genie Logiciel II
Serie 4 Genie Logiciel II
Département Informatique
Génie Logiciel II
Série TD N : 04.
Exercice 01 :
Rappel : L’objectif du pattern FACADE est de fournir une interface simplifiant l’emploi d’un sous-système.
Exercice 02 :
package app.facade;
import javax.swing.*;
import java.awt.Font;
UIManager.put("Button.font", font);
UIManager.put("Label.font", font);
int option;
do {
option = JOptionPane.showConfirmDialog(
null,
"Had enough?",
JOptionPane.YES_NO_OPTION);
-La classe JOptionPane facilite l’affichage d’une boîte de dialogue. Indiquez si cette classe est une façade, un utilitaire ou une
démo. Justifiez votre réponse.
-Peu de façades apparaissent dans les bibliothèques de classes Java. Pour quelle raison ?
Exercice 03 :
Produisez un nouveau diagramme de classes pour une conception laissant chaque objet intéressé s’enregistrer pour recevoir les
événements du curseur. Veillez à tenir compte du champ affichant la valeur du curseur.
Excercice04 :
package app.construction;
et :
package app.construction;
Ce code compile correctement tant que vous ne retirez pas les marques de commentaire //.
Questions :
Expliquez l’erreur qui se produira si vous retirez les marques de commentaire, permettant ainsi à la super-classe Fuse d’accepter
un nom dans son constructeur.
Correction Série 04
Voici quelques différences notables entre une démo et une façade :
1. Une démo est généralement une application autonome alors qu’une façade ne l’est généralement pas.
2. -Une démo inclut généralement un échantillon, ce qu’une façade ne fait pas.
3. Une façade est généralement configurable, pas une démo.
4. Une façade est prévue pour être réutilisée, pas une démo.
5. Une façade est prévue pour être utilisée en production, pas une démo.
Exercice 02
La classe JOptionPane est l’un des exemples peu nombreux d’une façade dans les bibliothèques de classes Java. Elle est utilisable
en production, configurable et est prévue pour être réutilisée. Avant toute chose, JOptionPane réalise l’objectif du pattern
FACADE en fournissant une interface simple qui facilite l’emploi d’une classe JDialog. Vous pouvez soutenir qu’une façade
simplifie un "sous-système" et que la classe JDialog seule ne remplit pas les conditions pour être un sous-système. C’est toutefois
la richesse des fonctionnalités de cette classe qui donne toute sa valeur à une façade.
Sun Microsystems incorpore de nombreuses démos dans son JDK. Ces classes ne font toutefois jamais partie des bibliothèques de
classes Java. C’est-à-dire qu’elles n’apparaissent pas dans les packages nommés avec le préfixe java. Une façade peut appartenir
aux bibliothèques Java, mais pas les démos. La classe JOptionPane possède des dizaines de méthodes statiques qui font
Effectivement d’elle un utilitaire ainsi qu’une application de FACADE. Toutefois, à stricte-ment parler, elle ne remplit pas les
conditions de la définition dans UML d’un utilitaire, laquelle exige que toutes les méthodes soient statiques.
Voici quelques points de vue acceptables mais opposés concernant la pénurie de façades dans les bibliothèques de classes Java.
- En tant que développeur Java, vous êtes bien avisé de développer une profonde connaissance des outils de la bibliothèque. Les
façades limitent nécessairement la façon dont vous pouvez appliquer n’importe quel système. Elles seraient une distraction et un
élément éventuel de méprise dans les bibliothèques dans lesquelles elles apparaîtraient.
- Les caractéristiques d’une façade se situent quelque part entre la richesse d’un kit d’outils et la spécificité d’une application.
Créer une façade requiert d’avoir une certaine idée du type d’applications qu’elle supportera. Il est impossible de prévoir cela
compte tenu de l’immense diversité du public utilisateur des bibliothèques Java.
- La présence rare de façades dans les bibliothèques Java est un point faible.
Excercice 03
La nouvelle conception permet aux composants dépendants du curseur de s’enregistrer pour être notifiés et de s’actualiser ainsi
eux-mêmes. C’est une amélioration discutable, mais nous restructurerons à nouveau la conception vers une architecture
Modèle-Vue-Contrôleur.
EXCERCICE 04 :
Le compilateur générera un message d’erreur dont la teneur sera à peu près la suivante :
Constructeur Fuse() super implicite indéfini pour un constructeur par défaut. Constructeur explicite obligatoire.
Cette erreur se produit lorsque le compilateur rencontre la classe QuickFuse et fournit un constructeur par défaut. Celui-ci
n’attend pas d’argument et invoque, à nouveau par défaut, le constructeur de la super-classe sans argument. Toutefois, la
présence d’un constructeur Fuse() qui accepte un paramètre String signifie que le compilateur ne fournira plus de constructeur
par défaut pour Fuse. Le constructeur par défaut de QuickFuse ne peut alors plus invoquer le constructeur de la super- classe
sans argument car il n’existe plus.