Discussion :

[Henry22]

Bonjour,

J'ai un exercice à faire. Je comprends qu'il faut simuler le patron de conception singleton. Par contre, je sais pas ce qu'est une classe de logging. De plus, je ne sais pas ce que sont des messages formatés pour le log. Pouvez vous m'expliquer la deuxième partie de l'énoncé s'il vous plaît?

Je vous remercie d'avance

Voici l'exo:

Le singleton est un patron de conception qui permet de ne créer qu'une seule instance d'une classe. Pour cela , on utilise une méthode de classe appelée getInstance() pour récupérer l'unique instance de la classe.

Illustrer le fonctionnement du singleton avec une classe de logging. Cette classe permettra d'afficher à l'écran des messages formatés pour le log. On ajoutera en particulier la date à tout message loggé.

[Baptiste Wicht]

Le logging est le fait de conserver des informations ou des événements dans un "journal" (fichier texte ou base de données).

Dans ton cas, il te suffit de créer une classe avec une méthode log(String message) et qui affichera dans la console quelque chose comme :

Date : message

Dans la pratique, il existe des APIs de logging telle que log4j qui te permettent de tenir des logs très détaillés et au formattage précis. On utilise en général des niveaux de logs différents en fonction de l'importance ou l'impact de ce qu'on loggue (trace, message, erreur, warning, ...).

Voici un exemple pour Log4J :

09:34:53,222 DEBUG ConnectionManager:444 - opening JDBC connection

[Henry22]

Salut,

Merci de m'avoir répondu.
Je comprends bien qu'il faut créer une classe avec la méthode log. Mais pourquoi appeller cette méthode log? Et que faut il mettre dans cette méthode. Ce n'est pas assez clair, pourrais tu être un peu plus précis s'il te plaît?

Merci

[Baptiste Wicht]

Salut,

Merci de m'avoir répondu.
Je comprends bien qu'il faut créer une classe avec la méthode log. Mais pourquoi appeller cette méthode log? Et que faut il mettre dans cette méthode. Ce n'est pas assez clair, pourrais tu être un peu plus précis s'il te plaît?

Merci

Tu peux appeller cette méthode comme tu veux, je l'ai appellée log car elle va permettre de "logguer" un message.

Une simple méthode de log serait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public void log(String message){
    System.out.println("Log : " + message);
}

Dans, ton cas, tu peux y ajouter des informations, comme la date du log par exemple.

[Astartee]

Pourquoi appeller cette méthode log ? Bah parce que c'est le but de l'exercice
Que faut il mettre dans cette méthode ? Bah ce que tu veux
Bon, je suppose qu'en fait tu n'as toujours pas compris ce qu'est le "logging" et donc ni à quoi ça sert (pourquoi appeller la méthode log) ni bien sûr ce que ça doit faire (que faut il mettre dans la méthode)


Un "log" ou un "journal" sert à conserver des traces de ce que fais ton programme : début et fin d'un traitement, messages d'erreur en cas de problème...
Ça permet de savoir un minimum ce qui se passe dans la "boîte noire" qu'est ton programme, afin de vérifier que tout se passe bien et de pouvoir plus facilement régler les problèmes s'il y en a.

Le plus souvent les API de logging permettent d'écrire les messages sur différents supports (affichage dans une console, enregistrement dans un fichier, etc), sous un format paramétrable (affichage ou non de l'heure du message, etc), et avec plusieurs niveaux de message (par exemple : debug pour les informations qu'on ne veut voir que pendant le développement, info pour les traces qui disent simplement ce que le programme est en train de faire, warn pour les erreurs qui ne bloquent pas le programme, error pour les erreurs critiques).

Exemple concret.

Tu pourrais obtenir des traces de ton programme avec de simples "System.out.println" qui t'afficheraient des messages dans une console :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public static void main(String[] args) {
   System.out.println("Début du traitement");
   try {
      while (variable > 0) {
         int variable = getMaVariable();
         System.out.println("traitement pour variable=" + variable);
         try {
            int result = traitement(variable);
            System.out.println("resultat=" + result);
         }
         catch (MonExceptionPasGrave e) {
            System.out.println("ATTENTION : " + e.getMessage());
         }
      }
   }
   catch (MonExceptionTresGrave e) {
      System.out.println("ERREUR BLOQUANTE : " + e.getMessage());
   }
   System.out.println("Fin du traitement");
}

Cependant, l'affichage dans une console c'est dur à conserver (mieux vaut mettre ça dans un fichier si on veut pouvoir le relire plus tard), tous les messages sont confondus (les messages d'erreur sont perdus au milieu de l'énorme quantité de messages de débug), et si l'on veut modifier le formatage des messages ou l'endroit ou l'on enregistre les messages, il faut refaire tout le code...

D'où l'idée de déléguer tout ce qui est formatage et écriture du message à une classe qui va centraliser ces traitements.
Le code s'écrirait alors ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public static void main(String[] args) {
   Logger logger = ...; // ici on initialise le logger
   logger.logInfo("Début du traitement");
   try {
      while (variable > 0) {
         int variable = getMaVariable();
         logger.logDebug("traitement pour variable=" + variable);
         try {
            int result = traitement(variable);
            logger.logDebug("resultat=" + result);
         }
         catch (MonExceptionPasGrave e) {
           logger.logWarning("ATTENTION : " + e.getMessage());
         }
      }
   }
   catch (MonExceptionTresGrave e) {
      logger.logError("ERREUR BLOQUANTE : " + e.getMessage());
   }
   logger.logInfo("Fin du traitement");
}

La classe Logger est ici une classe fictive, mais qui s'inspire fortement des API de logging existantes
Au moment de l'initialisation du logger, on définit où les messages seront écrit et selon quel format.
Il est possible de définir plusieurs fichiers de log, l'un ne contenant que les messages d'erreur et d'information et l'autre contenant tous les messages de débug : c'est la classe logger qui s'occupera d'écrire les messages dans ces deux fichiers à la fois.
Il est possible que l'initialisation du logger se fasse par la lecture d'un fichier de configuration : ainsi pas besoin de tout recompiler lorsque l'on veut modifier le format des messages, ajouter un fichier de log, etc.
Bref, ça offre plein de possibilités de configuration.

[Astartee]

Maintenant, quel est le rapport entre le pattern "singleton" et une classe de logging ?

Eh bien, dans les API de logging existantes, on initialise souvent le logger par une expression de la forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Logger logger = Logger.getLogger("nom du logger");

Et derrière, la méthode getLogger s'assure de ne créer qu'une seule instance de chaque type de logger (je suppose que c'est pour éviter des accès concurrents par deux instances de classe à un même fichier).

En fait, pour être plus exacte, dans les API existantes on a la notion de logger et d'appender.
L'appender est vraiment l'entité qui écrit dans un fichier/flux/etc.
Le logger peut être associé à plusieurs appenders (d'où l'écriture d'un même message dans plusieurs fichiers/flux/etc).