:: Enseignements :: ESIPE :: E4INFO :: 2013-2014 :: Programmation Orientée Objet - Design Pattern ::
Oracle a relivré le JDK mais, mauvaise surprise, ils ont supprimé tout ce qui concerne les Logger. On va devoir tout recoder !
Un logger est un objet sur lequel on peut envoyer des messages, avec différents niveaux de sévérité. On peut écrire des messages d'erreur (niveau ERROR), des messages d'avertissement (niveau WARNING), des messages informatifs (niveau INFO), ou des messages de débogage (niveau DEBUG). Les niveaux sont ordonnés : DEBUG, INFO, WARNING et enfin ERROR.
Un logger dispose de quatre méthodes correspondant chacune à l'envoi d'un message avec un niveau particulier.
Le logger lui-même a un niveau qui est le niveau à partir duquel il va effectivement traiter les messages. Par exemple, un logger de niveau WARNING va effectivement traiter les messages de niveau WARNING et ERROR qu'on lui a envoie, mais il « jettera » simplement ceux de niveau DEBUG ou INFO. Ainsi, un message de niveau DEBUG écrit sur un logger de niveau WARNING sera perdu. Par contre, si on change le niveau du même logger en DEBUG, les prochains message de niveau DEBUG seront traités (pour être par exemple affichés sur la console). On peut configurer le niveau du logger à sa création ou via une méthode setLevel.
![[LOGO]](http://igm.univ-mlv.fr/ens/resources/mlv.png) | Decorator & Composite |
Oracle a relivré le JDK mais, mauvaise surprise, ils ont supprimé tout ce qui concerne les Logger. On va devoir tout recoder !
Un logger est un objet sur lequel on peut envoyer des messages, avec différents niveaux de sévérité. On peut écrire des messages d'erreur (niveau ERROR), des messages d'avertissement (niveau WARNING), des messages informatifs (niveau INFO), ou des messages de débogage (niveau DEBUG). Les niveaux sont ordonnés : DEBUG, INFO, WARNING et enfin ERROR.
Un logger dispose de quatre méthodes correspondant chacune à l'envoi d'un message avec un niveau particulier.
Le logger lui-même a un niveau qui est le niveau à partir duquel il va effectivement traiter les messages. Par exemple, un logger de niveau WARNING va effectivement traiter les messages de niveau WARNING et ERROR qu'on lui a envoie, mais il « jettera » simplement ceux de niveau DEBUG ou INFO. Ainsi, un message de niveau DEBUG écrit sur un logger de niveau WARNING sera perdu. Par contre, si on change le niveau du même logger en DEBUG, les prochains message de niveau DEBUG seront traités (pour être par exemple affichés sur la console). On peut configurer le niveau du logger à sa création ou via une méthode setLevel.
Exercice 1 - le commencement
Dans un premier temps, on ne s'intéresse qu'à du logging sur la console, on va donc créer une classe ConsoleLogger, qui fournira le minimum :
- un constructeur par défaut et un constructeur permettant de régler le niveau de log
- les 4 méthodes nécessaires à l'envoi des messages de log correspondant aux 4 niveaux. Le traitement effectif consistera simplement à envoyer les messages de log sur la sortie standard (DEBUG, INFO, WARNING) ou la sortie erreur standard (ERROR).
- Faire le schéma UML de la classe ConsoleLogger et écrivez là.
Exercice 2 - nouveau besoin !
On veut maintenant pouvoir créer un logger spécialisé pour écrire les messages dans un fichier.
Ecrivez la classe FileLogger.
Quelles modifications devez-vous apporter à la classe ConsoleLogger ?
- Expliquez en quoi vous allez modifier votre conception pour prendre en compte cette nouvelle classe FileLogger à écrire ?
- Refaites votre schéma UML
Ecrivez la classe FileLogger.
Quelles modifications devez-vous apporter à la classe ConsoleLogger ?
Exercice 3 - nouveau besoin !
Le chef de projet avait « oublié » une petite précision : il faut pouvoir envoyer les messages de log sur les deux logger. Bien sûr, le code client ne devra pas doubler les appels aux fonctions du logger.
- Quelles modifications apporterez-vous à votre diagramme UML ?
- Modifiez votre code en conséquence
- Quel Design Pattern avez-vous utilisé ? Expliquez le principe de sa mise en œuvre
Exercice 4 - nouveau besoin !
Les fichiers de logs produits sont très pratiques mais, quand le client appelle suite à un problème dans le fonctionnement du logiciel, il est difficile de retrouver les logs dans les fichiers qui sont très volumineux.
On souhaite donc pouvoir préfixer automatiquement les messages avec la date et l'heure courante. Cette nouvelle fonctionnalité devra pouvoir s'appliquer, optionnellement à chaque logger. Par exemple, on pourrait avoir un client utilisant un ConsoleLogger sans horodatage et un FileLogger avec horodatage ; et un autre client faisant l'inverse. C'est donc au moment de la création du Logger que l'horodatage sera activé ou pas.
Le chef de projet a des idées précises sur « ce qui ne doit pas être fait » :
il est interdit de dupliquer le code dans les deux classes ConsoleLogger et FileLogger (il souhaite factoriser au maximum le code d'horodatage)
Le code d'horodatage devra pouvoir être utilisé sans aucune modification avec d'autres logger
- Quel Design Pattern va vous permettre d'implémenter cette évolution en respectant les contraintes techniques posées par le chef de projet. Expliquez le principe de sa mise en œuvre.
- Quelles modifications apporterez-vous à votre diagramme UML ?
- Ecrivez le code nécessaire et illustrer son utilisation par un exemple
Exercice 5 - nouveau besoin !
les loggers à utiliser, leur niveau, et la présence ou pas d'horodatage doivent pouvoir être décrits dans un fichier de configuration. L'idée est donc que ce fichier sera lu au lancement du programme et permettra de contrôler la création de vos Loggers.
- Décrivez votre conception pour prendre en compte ce nouveau besoin
- Quelles modifications apporterez-vous à votre diagramme UML ?
- Avez-vous mis en œuvre un ou plusieurs Design Patterns ? Si oui, lesquels ? Expliquez si besoin les principes de leur mise en œuvre en une simple phrase.
© Université de Marne-la-Vallée