Discussion :

[WriteLN]

Bonjour à tous,

J'aurais besoin de vos avis concernant la conception orientée objet en .net.

Voici le contexte:

- J'ai créé une classe clsLog qui à des méthodes et membres pour permettre d'écrire à partir de n'importe ou une ligne dans un fichier log. Cette classe est instanciée avec un chemin vers le fichier log et utilisée partout dans mon appli.
- Une classe du même acabi pour une gestion statistique
- Une classe de gestion des paramètres de mon application (stocke et récupère les paramètres à partir d'un fichier XML)
- Une classe de gestion de ma connexion SQL.

Il faut savoir que la classe de gestion des stats et SQL font appels à la classe de gestion des logs.
D'autres classes de mon applis vont utiliser la classe de stats, de logs, ...

Quelle est la meilleur option:

- Déclarer et instancier de manière globale ces classes au démarrage et les utiliser dans toutes mes autres classes? Aie Aie Aie... Si je veux utiliser une classe dans un autre projet qui n'utilise pas la classe de log, ca va plantouiller.
- Instancier une nouvelle instance de cette classe partout ou c'est nécessaire? Aie Aie Aie... Il risque d'y avoir pas mal d'instancent...
- Passer la référence aux classes nécessaires au objets qui veulent les utiliser? Au début de l'appli je les instancie de manière globale, et chaque classe qui doit les utiliser recevra une référence à cette instance.
- Autre solution mais la je sèche totalement. Je suis pas encore très à l'aise avec la conception objet et surtout !!! L'encapsulation et la réusabilité.

Merci d'avance pour vos idées et retour d'expérience.

Un développeur en panique

[tomlev]

Le design pattern Singleton est ce qu'il te faut je pense...
http://www.dofactory.com/Patterns/PatternSingleton.aspx

Tu crées une propriété statique (Shared en VB) dans ta classe, qui renvoie l'instance unique de cette classe.
Quelque chose comme ça (désolé pour les erreurs de syntaxe, je code pas en VB d'habitude) :

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
 
Public Class clsLog
 
    Private Shared _instance As clsLog
 
    Public Shared Property Instance As cslLog
        Get
            If _instance Is Nothing Then _instance = New clsLog()
            Instance = _instance
        End Get
    End Property
 
    ' ...
    ' Le reste du code...
    ' ...
 
End Class

A noter : l'instance n'est créée que lors du premier appel à la propriété, mais rien n'empêche de la créer dans le constructeur statique de la classe.

Pour l'utiliser, à partir de n'importe où, tu peux faire :

Code :

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

1
2
 
    clsLog.Instance.Log("blabla")

(en supposant que tu aies une méthode Log...)

[WriteLN]

Merci beaucoup, je vais essayer d'aller dans cette direction.

Juste une petite question, est-il possible d'adapter ton exemple de singleton mais avec passage de paramètres?
Je ne trouve nulle part d'exemple pour le faire.


Si quelqu'un à d'autres avis, n'hésitez pas à me faire signe

[tomlev]

est-il possible d'adapter ton exemple de singleton mais avec passage de paramètres?

Je ne suis pas sûr que ça aurait vraiment un sens... vu qu'il n'y a qu'une instance de la classe, elle est toujours créée de la même façon, ça semble logique.
Si tu tiens vraiment à le faire, tu peux créer l'instance unique dans une fonction statique (Shared) qui prend des paramètres, au lieu de la créer dans la propriété :

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 Class clsLog
 
    Private Shared _instance As clsLog
 
    Public Shared Property Instance As cslLog
        Get
            Instance = _instance
        End Get
    End Property
 
    Public Shared Sub CreateInstance(nom_fichier_log As String)
        _instance = New clsLog(nom_fichier_log)
    End Sub
 
    ' ...
    ' Le reste du code...
    ' ...
 
End Class

Mais il ne faut pas oublier d'appeler cslLog.CreateInstance avant d'essayer de l'utiliser...

[Keihilin]

Quelques remarques :

• N'utilise pas un Singleton là ou une classe statique suffit.
  Je sais, c'est très à la mode le Singleton, mais je vois pas mal de monde l'utiliser à toute les sauces pour faire "pro" alors que ça ne se justifie pas...
• Si tu tiens à ton Singleton, mais que tu as besoin de passer des paramètres, regarde si tu peux déplacer ces paramètres vers les méthodes plutôt que vers le constructeur.
• Si tu ne peux pas, peut être que le pattern "Flyweight" te serait plus utile.

[tomlev]

N'utilise pas un Singleton là ou une classe statique suffit.

Tiens, je me suis souvent fait cette réflexion, mais je me disais que le pattern Singleton devait exister pour une bonne raison... c'est vrai que ça ne fait pas beaucoup de différence d'utiliser une classe statique, et c'est plus pratique.

Quand au Flyweight, dans le cas de WriteLN, ça pourrait effectivement être une bonne option, surtout si son appli a plusieurs logs...

[olsimare]

Bonjour.

Tout le mode a déjà utilisé le console.writeline.

Console est une vraie classe statique non instanciable.

C'est pas la seule méthode de class statique du framework (textrenderer, messagebox ...).

Donc j'ai opté pour le même fonctionnement en déclarant les méthodes de ma class log en Shared et en positionnant un constructeur Private Sub New (si quelqu'un sait comment interdire la création implicite du constructeur comme pour une class Static de c# sans cette bidouille, je suis preneur).

Et ça donne : log.write(a,b,c)

Cdt.

[tomlev]

Oui, mais si tu veux gérer différents logs (par exemple un pour les erreurs, un pour les évènements...), tu ne peux pas !
Alors qu'avec le pattern Flyweight, tu peux faire quelque chose comme ça :

Code :

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

1
2
3
 
LogFactory.GetLog("event").Write("...")
LogFactory.GetLog("error").Write("...")

(J'ai adapté le pattern à ma sauce, normalement la Factory n'est pas statique, mais c'est plus pratique comme ça...)
Enfin bref, peut-être que je me prends la tête pour rien, mais conceptuellement c'est intéressant...

[Keihilin]

Tiens, je me suis souvent fait cette réflexion, mais je me disais que le pattern Singleton devait exister pour une bonne raison...

Ben si j'étais d'humeur trolleuse, je répondrai qu'il existe pour que certains développeurs puissent avoir l'impression d'être des architectes

Plus sérieusement, la différence majeure entre le Singleton et une classe statique c'est le support de l'héritage.
Partant de là, il est assez facile de déterminer les cas dans lesquels le singleton se justifie...

[tomlev]

Ben si j'étais d'humeur trolleuse, je répondrai qu'il existe pour que certains développeurs puissent avoir l'impression d'être des architectes

Plus sérieusement, la différence majeure entre le Singleton et une classe statique c'est le support de l'héritage.
Partant de là, il est assez facile de déterminer les cas dans lesquels le singleton se justifie...

Le support de l'héritage ? Je ne comprends pas trop ce que tu veux dire là... pour récupérer ton instance de Singleton, tu es obligé d'utiliser une méthode statique, et une méthode statique ne peut pas être redéfinie dans une classe dérivée... Donc si tu as une classe singleton A, et une classe singleton B qui hérite de A, la méthode B.GetInstance() te renverra la même chose que A.GetInstance(), donc un A et non un B. Ou alors il faut définir une méthode GetBInstance()...

[Keihilin]

Le support de l'héritage ? Je ne comprends pas trop ce que tu veux dire là...

bon ben super shématiquement :

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
 
public class A
{
	private static A _instance = new A();
	public static A Instance
	{
		get { return _instance; }
	}
	protected A()
	{
	}
	public virtual void Method1()
	{}
	public virtual void Method2()
	{}
}
 
public class B : A
{
	public  B()
	{
	}
}

alors bon ok, la légitimité du constructeur Protected pour un singleton peut se discuter.

Maintenant, ça marche aussi dans l'autre sens , on pourrait imaginer :

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
 
public class A : Z
{
	private static A _instance = new A();
	public static A Instance
	{
		get { return _instance; }
	}
	private A()
	{
	}
	public override void Method1()
	{}
	public override void Method2()
	{}
}

chose qu'on ne ferrait pas avec une classe statique...

[tomlev]

jusque là, d'accord, mais comment tu récupères ton instance de B ?

[Keihilin]

Comme tu le souhaites...

Tu peux faire de B un singleton...ou pas.

[olsimare]

Bonjour.

Personnellement un flyweigth pour 3 ou 4 objets, je vois pas trop l'intérêt ...

Pour utiliser 4 fichiers de sortie tu fais :
log.write(nomdufichier,b,c)
et un bon gros select case sur le nomdufichier pour router le message vers le bon fichier.

C'est pareil et ça reste compréhensible du commun des mortels !

PS : j'arrête sur ce post, ça va tourne au débat d'idée !

Cdt.

[tomlev]

Pour utiliser 4 fichiers de sortie tu fais :
log.write(nomdufichier,b,c)
et un bon gros select case sur le nomdufichier pour router le message vers le bon fichier.

Argh ! C'est pas beau
Ben oui quoi, je suis un peu maniaque et j'aime bien trouver des solutions élégantes... mais c'est vrai que ton approche du problème est plus pragmatique

[WriteLN]

Bonjour à tous,

Je vois que je suis pas le seul à essayer de concevoir propre et objet.
Le singleton marche super bien dans mon cas mais le seul truc que je vois, c'est qu'il faut absolument lui passer un paramètre qui est le répertoire de stockage (paramètrable).
Pour ce faire, j'ai suivi la proposition de Keihilin
En déportant le chemin d'accès vers le fichier log dans une propriété de ma classe.
Dans la méthode ->write("message", type.critical) je vérifie si le chemin d'accès a été définit. Si ce n'est pas le cas, on écrit dans le c:\temp par défaut.

A présent, dans toute mon appli, je peux faire

Code :

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

clsLogEngine.instance.Write("message", type.critical)

Idem pour ma classe de paramètres, ma classe de gestion de l'utilisateur et ma classe de gestion des statistiques.

Je vais quand même me pencher sur le flyweight pattern et voir si je peux l'exploiter.

Pas toujours facile de savoir vers quel pattern se tourner pour rester le plus cohérent possible.

Merci à tous pour votre échange d'idées.

D'autres sont bienvenues :-)

Bonne journée.

[Keihilin]

Pour ce faire, j'ai suivi la proposition de Keihilin
En déportant le chemin d'accès vers le fichier log dans une propriété de ma classe.

Il faut faire attention avec cette approche, elle peut provoquer quelques soucis si ta classe est mal utilisée...

Demande-toi quel va être le comportement si la propriété qui gère le chemin d'accès change entre 2 appels ?

Schématiquement, je ferai quelque chose comme ça :

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
25
26
27
28
29
30
31
 
public class clsLogEngine
{
	private const string defaultEngineName = "Default";
 
	private static Hashtable _cache = new Hashtable();
 
	private string _name;
	private string _path;
 
	private clsLogEngine(string name, string path)
	{
		_name = name;
		_path = path;
	}
	public void Write(string message) {}
 
	public static clsLogEngine GetInstance()
	{
		return GetInstance(defaultEngineName);
	}
	public static clsLogEngine GetInstance(string name)
	{
		return _cache[name] as clsLogEngine;
	}
	public static clsLogEngine CreateInstance(string name, string path)
		{
			clsLogEngine engine = new clsLogEngine(name, path);
			_cache.Add(name, engine);
		}
	}

Sous-entendu les tests nécessaires --> objet avec le même nom déjà en cache, objet non-trouvé en cache, etc, etc...