Discussion :

[Graffito]

Bonjour,

Contexte :
Une forme L comporte un "Log" qui permet d'afficher une trace des actions venant d'autres formes A, B, C ... comme par exemple :

• "Init form1 OK : 25 enr." ,
• "Reset Form2 : 5 erreurs, 4 warnings",
• "Sauvegarde configuration sur fichier xxx.ini",
• ...

Question:
Quelles solutions proposeriez-vous pour implémenter dans chaque forme A, B, C un appel du type AddToLog(form L, string Message) ou L.AddToLog(string Message) ou autre ?[/B]

[LooserBoy]

Dans les grandes lignes:
Je separerais le log de la forme L pour en faire un objet à part proposant une methode AddToLog et qui leverait un evenement pour dire qu'il a quelque chose de plus dans sa liste d'enregistrements.
Ainsi, la forme L qui doit afficher les enregistrement s'abonne à l'event pour se raffraichir et les objets (formes et autres) appellent la methode AddToLog.
Note: Afin d'eviter de se retrouver avec n instances du log, il faut absolument le traiter en singleton.

Voilou.

[Nikoui]

Je ferai ça "dans l'autre sens" : ajoute à chacune de tes formes A, B et C un evènement comme par exemple "ActionPerformed" avec la description de l'action dans les arguments de l'event.

Puis ta classe L s'abonne a chacune des formes A, B et C et "écoute" ce qu'il se passe pour logger à chaque levé d'un évènement

Edit : en fait je ferai ce que je viens d'écrire + ce qui est proposé juste au dessus : séparer le logger de la fenêtre affichant les logs (la aussi par des evenements).

[LooserBoy]

@Nikoui:
Le problème de ta solution est le suivant: le "logueur" est obligé de savoir qui va avoir besoin de lui. Pas très pratique et surtout pas souple pour un sou ! Tu ajoute une forme qui doit fournir des infos, t'es obligé et de créer ta forme et de modifier ton loguer.
Dans ma solution un loguer est a dispo pour tous ceux qui veulent enregistrer des infos et pour tous ceux qui veulent manipuler les infos qui circulent. tu crées ta forme qui appelle le logueur et fin! [EDIT]Une forme ou autre bien sûr! [/EDIT]

[Nikoui]

@LooserBoy :
En fait tout dépend de ce qu'on veut faire (avoir un logger accessible de partout, ou être capable d'observer des objets de n'importe où...).

Et en relisant le message d'origine je pense en effet qu'ici il s'agit du premier cas, et donc utiliser un logger "singleton" suffit à répondre au problème, avec la vue qui va bien comme tu le décris

Bon, pour me rattraper, je rajouterai : les enterprise library proposent déjà un logger très évolué et simple à mettre en place, ça peut être interressant à étudier aussi )

[LooserBoy]

@LooserBoy :
En fait tout dépend de ce qu'on veut faire (avoir un logger accessible de partout, ou être capable d'observer des objets de n'importe où...).

Je ne suis pas partisant de faire un logueur qui soit ausi un observateur.
Je pense que ce serait plus propre qu'un observateur surveille le logueur et les message qui peuvent passer par là pour en analyser la substantifique moelle.
Plus un objet sera simple fonctionnellement et plus il sera facile à debugguer et faire evoluer. Si tu dois elaguer le code qui assure 25 fonctions differentes (dont dire papa/maman, faire le cafe, appeler le livreur de pizza et autres... ) pour tenter de corriger un bug ou de mettre en place une evolution (sauvegarder l'activité dans un fichier ou une bdd,...), tu va te faire une migraine des familles facon "nervous breakdown, comme on dit de nos jours" ...

[Nikoui]

Je le répète tout dépend de ce que tu veux faire et de ce que tu log. Par exemple tu peux avoir besoin de faire des choses dans le même genre que l'observateur d'évènement de windows, et dans ce cas ton logger va observer les modifications de tes données, plutôt que d'attendre une demande de log explicite de tes objets.

[Graffito]

Merci pour vos réponses.

Ainsi, la forme L qui doit afficher les enregistrement s'abonne à l'event pour se raffraichir et les objets (formes et autres) appellent la methode AddToLog.

J'aurai 2 questions concernant l'implémentation:

• Comment la forme s'abonne t'elle à l'event ?
• Comment une fonction de l'objet déclenche-t-elle l'event?

[hitech_tm]

D'abord tu doit déclaré un delegate (permet de déclarer un type référence qui permettra d'encapsuler plusieurs méthodes nommées ou anonymes).

public delegate void delegate1(object sender, string pMessage);


Puis dans chaque forme ou tu veut capturer l'événement tu doit déclaré
public event delegate1 AddToLog;

Et pour déclancher l'événement

if (AddToLog!= null)
{
AddToLog (this, e);
}

Et aussi déclaré dans la forme L pour ton exemple un méthode écouteur qui ecoute les événements dans chaque forme A,B,C..

A.AddToLog+= EventHandlerAddToLog;
B.AddToLog+= EventHandlerAddToLog;
C.AddToLog+= EventHandlerAddToLog;


public List<String> ListMessages = new List<string>();
public void EentHandlerAddToLog (object sender, string pMessage)
{
ListMessages.Add(pMessage);
}
pour tous résumer voiçi un exemple de code source :
http://www.4shared.com/file/32622811...ified=e9c4c5e0

[dahtah]

Salut, je serais plutôt de l'avis de LooserBoy. Tu découples ton log de ta form L. Ta classe log (singleton) propose des classes statics, que peuvent appeller n'importe quelle forme. Ta classe log génère des évènements de changement qu'écoute ta form L.
Ainsi ta classe Log n'a pas besoin d'avoir de références à tes formes A,B etC.
Bonne chance

[Graffito]

Merci à tous, j'essaye les delegate.

[ced600]

Dans les grandes lignes:
Je separerais le log de la forme L pour en faire un objet à part proposant une methode AddToLog et qui leverait un evenement pour dire qu'il a quelque chose de plus dans sa liste d'enregistrements.
Ainsi, la forme L qui doit afficher les enregistrement s'abonne à l'event pour se raffraichir et les objets (formes et autres) appellent la methode AddToLog.
Note: Afin d'eviter de se retrouver avec n instances du log, il faut absolument le traiter en singleton.

Voilou.

Je suis entiérement d'accord avec ceci.

Par contre j'utiliserais plutot une classe statique qu'un singleton.
En effet une classe de gestion de fichier de log offre des méthodes qui ne sont pas spécifique à une classe ou un type de classe mais qui doivent être accessible par tout le monde.

Toutes les classes peuvent en effet loguer ce qu'elles veulent.

En plus une classe statique est accessible comme un type sans instanciation dans le code C#

[SaumonAgile]

Je suis entiérement d'accord avec ceci.

Par contre j'utiliserais plutot une classe statique qu'un singleton.
En effet une classe de gestion de fichier de log offre des méthodes qui ne sont pas spécifique à une classe ou un type de classe mais qui doivent être accessible par tout le monde.

Toutes les classes peuvent en effet loguer ce qu'elles veulent.

En plus une classe statique est accessible comme un type sans instanciation dans le code C#

Tu pourrais vouloir avoir besoin de logs différents, avec un héritage du log de base, je resterais plutot sur du singleton (qui permet l'héritage).

[ced600]

Tu pourrais vouloir avoir besoin de logs différents, avec un héritage du log de base, je resterais plutot sur du singleton (qui permet l'héritage).

+1
En effet je n'avais pas pensé à cela mais j'ai trouvé un moyen de faire cela en statique.

Il faut penser en "état". Tes différentes classes de log sont des états de logs d'un controleur de log.

Tu fait ton controleur de log en statique. Tu implémente le design pattern d'etat dessus. Donc tu auras une classe abstract dont hériteront toutes les classes logs etat représentant un état du log.

Le changement de log se déroulera en fonction du composant où tu te trouves.

Genre le composant qui à la main change l'état du controleur de log, pour loguer à sa façon les événements

Donc au finale tu ne vois qu'une méthode statique, et tu as juste besoin de rajouter pour chaque composant la ligne qui appelle la méthode change etat.

Bon ok je vais chercher compliqué, mais cela m'a l'air sympas

[Nikoui]

je resterais plutot sur du singleton (qui permet l'héritage).

C'est pas censé être sealed un singleton ?

[SaumonAgile]

C'est pas censé être sealed un singleton ?

Puisqu'il faut être pointilleux, la classe de log de base doit être héritable (ni static ni sealed), et les log "réels" seront des singletons et hériteront de la classe de base.

Et pour que tout le monde soit content, voila un singleton lazy et thread-safe :

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
22
23
24
public sealed class Singleton
{
    Singleton()
    {
    }
 
    public static Singleton Instance
    {
        get
        {
            return Interne.instance;
        }
    }
 
    class Interne
    {
        // Pour le compilateur, cela évite que l'instance soit créée avant le premier accès.
        static Interne()
        {
        }
 
        internal static readonly Singleton instance = new Singleton();
    }
}

[Graffito]

Merci de toutes vos réponses.

Le problème initial étant résolu (bug non liée au sujet du post),
J'implémenterai définitivement mes classes après les vacances.

Bonnes fêtes à tous.