Interface de marquage et Enum

Bonjour,

J'ai besoin de maintenir une Factory au fil du temps sans devoir toucher au code.
Pour jouer avec cette Factory, je pensais utiliser un Enum
(clarté dans le code et pour l'utilisation)

Mais voila,
On ne peut pas modifier dynamiquement le contenu d'un Enum
(il est spécifié à la compilation)

En Java (car c'est de là que je viens ^^)
J'utilisais une interface de marquage,
Les Enums l'implémentaient et c'était tout bon,
(une nouveauté dans la Factory + un nouvel Enum fournit = PROFIT !!!)

En C#, les Enums ne peuvent implémenter/hériter d'autre objet.
Je me retrouve bloqué ^^'

Quelqu'un aurait une idée de comment faire en C# ?

Salut,
Effectivement il y a une sacrée différence entre java et c# avec les enum. En java un Enum est une classe pas en c#.
Donc pour toi le plus simple si tu veux reproduire le fonctionnement de en c# va falloir faire des classes pour chaque valeur de l'enum qui hérite de la même classe abstraite.
En c# l'enum est un type il est bien pratique et simple mais le code est dans le case. Alors qu'en java tu peux mettre le code dans l'enum lui même.

Hum le truc lourding Oo

Bon, je vais faire une AbstractFactory dans ce cas =/

Bonjour,
Bon je reviens à la charge sur mon problème d'interface de marquage.

J'essaye de trouver un moyen simple de reproduire ce mécanisme
Et j'aimerai votre avis ^^

Admettons une Factory nommée en circonstance.
J'y stocke une valeur, ici un int,
En fonction d'une clé, ici une string,
J'utilise une string au lieu d'une classe spéciale
Pour utiliser tous les mécanismes déjà implémentés par le Framework,
Qui seront (quasi) forcement mieux que si ça venait de moi ^^
(hashcode, equals, ...)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

public class Factory { public Dictionary<string, int> dico { get; private set; }   public Factory() { dico = new Dictionary<string, int>(); }   public void add(CType k, int v) { dico.Add(k, v); }   public int get(CType type) { return dico[type]; } }

---

La classe CType crée la "constante" à proprement parlé.
Elle utilise la reflexion pour distinguer les différents (faux) "enum"

Code:

---

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 32 33 34

public class CType { private static int index = 0;   private readonly string type; private readonly int val;   public string Name { get; private set; } public string FullName { get { return type + "." + Name; } }   public CType(string value) { this.type = new StackTrace().GetFrame(1) .GetMethod().DeclaringType.FullName; this.Name = value; this.val = index++; }   public override string ToString() { return Name; }   public static implicit operator string(CType type) { return type.FullName; }   public static implicit operator int(CType type) { return type.val; } }

---

LType1 et LType2 sont deux exemples de (faux) "enum"

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public class LType1 { public static CType UN = new CType("un"); public static CType DEUX = new CType("deux"); public static CType TROIS = new CType("trois"); }   public class LType2 { public static CType QUATRE = new CType("quatre"); public static CType CINQ = new CType("cinq"); public static CType SIX = new CType("six"); }

---

Le test suivant affiche les valeurs du dictionnaire
Ainsi que la façon dont ils sont stockés.

Code:

---

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 32

public class Test { public static void main() { Factory f = new Factory(); f.add(LType1.UN, 6); f.add(LType1.DEUX, 0); f.add(LType1.TROIS, 2); f.add(LType2.QUATRE, 3); f.add(LType2.CINQ, 3); f.add(LType2.SIX, 5); f.add(new CType("sept"), 10);   Console.WriteLine("{0}:{1} - {2}:{3} _ {4}:{5}", LType1.UN, f.get(LType1.UN), LType1.DEUX, f.get(LType1.DEUX), LType1.TROIS, f.get(LType1.TROIS)); Console.WriteLine("{0}:{1} - {2}:{3} _ {4}:{5}", LType2.QUATRE, f.get(LType2.QUATRE), LType2.CINQ, f.get(LType2.CINQ), LType2.SIX, f.get(LType2.SIX)); Console.WriteLine("{0}:{1}", new CType("sept"), f.get(new CType("sept"))); Console.WriteLine();   foreach (string s in f.dico.Keys) { Console.WriteLine(s); } } }

---

Ça affiche :

un:6 - deux:0 _ trois:2
quatre:3 - cinq:3 _ six:5
sept:10

Archi_II.LType1.un
Archi_II.LType1.deux
Archi_II.LType1.trois
Archi_II.LType2.quatre
Archi_II.LType2.cinq
Archi_II.LType2.six
Archi_II.Program.sept



Allez y, grondez moi ^^

Juste pour rappel,
Je recherche un moyen simple, efficace, sécurisé et performant
(rien que ça ^^)
Pour accéder à des données évolutives ...

EDIT : ajout d'un test et le résultat du test ^^

Je ne te suis qu'à moitier. C'est un étrange truc que tout cela, une factory qui n'est autre qu'un dictionnaire, des éléments fourni par la factory ne sont pas instancié mais stocké dans le dico... bref surement que les notations ne correspondent pas au pattern et au standard.
Si tu veux faire de 'faux' enum qui ressemble à java et qui implémente un interface de marquage. Et bien il suffit de créer une classe qui implémente cette interface, et qui possède quelques propriétés (un entier et une string) pour gérer les instances, pourquoi pas les utiliser de façon static comme tu le fais. Le dictionnaire et la factory ne me semble utile ici.

Code:

---

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 32 33 34 35 36 37 38

public class MonEnum : IMonMarquage {   public static readonly MonEnum UN = new MonEnum ("UN",1); public static readonly MonEnum DEUX= new MonEnum ("DEUX",2); public static readonly MonEnum TROIS= new MonEnum ("TROIS",3); public static readonly MonEnum QUATRE= new MonEnum ("QUATRE",4); public static readonly MonEnum CINQ= new MonEnum ("CINQ",5);   private readonly string name; private readonly int value;       public CType(string name, int val) { name= name; value= val; }   public override string ToString() { return name; }   public static implicit operator string(CType type) { return this.name; }   public static implicit operator int(CType type) { return this.value; }   /*TODO:IMPLEMENTER LES METHODES DE MARQUAGE...*/ }

---

La valeur que je mentionne n'est pas un int en fait.

C'est un Type que j'instancie à la demande.

J'ai besoin d'une Factory pour rassembler un ensemble d'éléments proprement
(un seul objet d'accès, le seul qui contrôle le tout)
Le dictionnaire me permet de rechercher en temps constant amorti un élément
Et aussi d'éviter les conflits.

Mon but ultime (^^) est de pouvoir gérer
La fabrication de composant simplement
Et pouvant être mise à jour
(la fabrication pas le composant ^^)
Dans le futur sans devoir toucher au code
(à la manière d'un plugin)

En fait tu veux charger dynamiquement une lib permettant de créer des objets respectant une interface utilisable par le code principal qui ne change pas.
http://drq.developpez.com/dotnet/art...plugin/csharp/

Sinon pour reprendre mon code les MonEnum :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class MonEnum : AbstractFactory { // comme avant// public override Type1 getInstance1() { // super code modifiable fabirquant un objet de type Type1 return type; }     public override Type2 getInstance2() { // super code modifiable fabirquant un objet de type Type2 return type; } .... }

---

MS et ses dll "en veux tu en voila" ... :?
Je m'y ferai jamais =/
Malheur à moi qui fait devoir en faire plein -__-

J'ai pas compris ton dernier code ...
Tu veux que je rende non modulaire quelque chose de modulaire ? Oo

Si j'ai une interface qui spécifie N getInstance (dans ton exemple)
J'oblige le développeur à avoir N Type Oo
C'est pas un peu (beaucoup) contradictoire avec ce que je souhaite ? Oo

Si mon "Enum" fabrique lui même ses composants ...
Ça laisse le soin au développeur d'instancier comme il le souhaite son composant ...
Je trouve pas ça très safe Oo

Enfin,
Si les noms sont fixés par l'interface
(getInstance1, getInstance2)
Je retrouve comment mes composants ? Oo
Qui me dit que getInstance1 est de tel type, etc ... ?

Je vais exploité le coté dll
( Il y a quelque chose de spéciale à faire sous VS2010 pour faire une dll ?
. J'ai pas cherché ^^' Mais il doit y avoir quelque chose ... non ? Oo )

Et c'est vrai que je réfléchi trop en terme de programmation,
Et non en terme d'IHM =S
En fait le soucis c'est que je suis sur un projet
Où on me définit le cahier des charges à la volée =/
Donc j'essaye d'élaborer au mieux mon architecture
Pour éviter de devoir la remanier toutes les semaines =/

En fait, si c'est une IHM qui gère le tout,
De simple string suffisent pour accéder à la factory
Mais si on veux l'accès dans un développement autre,
Les Enum sont bien pratique
(évite les fautes de frappes, vérifier à la compilation, ...)

Tout ce que je sais c'est qu'il faut que je sauvegarde le moins possible,
Que je crée la quasi totalité dynamiquement ...
C'est pour ça que je comptait stocker des Type
Là va falloir que je stocke des accès a une dll ... ? Oo

Et ca t'interesse pas un vrai conteneur d'injection de dépendances?

Citation:

---

Envoyé par Nathanael Marchand

Et ca t'interesse pas un vrai conteneur d'injection de dépendances?

---

Tu pourrais développer ? :)

PS : Hum, j'ai beau avoir Notification instantanée par mail d'activé, Je ne reçois rien -__- C'est frustrant Oo

Un truc comme Spring qui est la référence pour le Java... il doit y avoir Castle, Unity en C#. Les EntLib utilisent ça.

Du coup le développeur il a des ses mains une class abstract unique. Et tu inject la factory de ton choix dans son programme qui fournira la bonne class en fonction de la conf de l'injection.

Citation:

---

Envoyé par brachior

Tu pourrais développer ? :)

PS : Hum, j'ai beau avoir Notification instantanée par mail d'activé, Je ne reçois rien -__- C'est frustrant Oo

---

Effectivement, tu peux regarder mon article sur Unity qui explique le principe. Ca remplit tout à fait le rôle du dictionnaire à objets en plus mieux :D

Tu peux également regarder du côté de MEF (que je n'ai jamais trop creusé)

J'ai jamais fait de J2EE (j'en ferais l'année prochaine ^^)
J'ai regardé un peu le Wiki sur Spring ...
Je sais pas encore si c'est vraiment adéquat pour le projet sur lequel je suis.

Je vais lire l'article de Nathanael sur Unity pour voir ^^

J'espère juste que ça va pas casser toute mon archi =/
Déjà que le coup des dll ça chamboule pas mal =/
D'ailleurs si vous avez de la lecture sur le partage de code via des dll ...

J'ai jamais autant lu de ma vie Oo lol

Si vous avez d'autres conseils/lectures à me proposer,
N'hésitez surtout pas ^^ Je suis preneur ^^

Hum,
J'aime bien le principe d'Unity ...
Il peut me simplifier pas mal de chose Oo
Reste le problème de l'évolution de ma factory (UnityContainer)
Dans ton article tu décris un processus par fichier de configuration,
mais il est donc fixé une bonne fois pour toute =/

Il y a un moyen d'ajouter à la volée ?

Autre question qui n'a pas vraiment de rapport
(dites le moi si je doit ouvrir un nouveau topic ^^)

J'ai 2 grands type d'objet,
Appelons les A et B,
Le but de mon programme est de pourvoir
Rajouter des composants de type A ou B
Donc on pencherai pour 2 interfaces IA et IB données en dll
Mais voila, il y a des choses dans A et B qui sont déjà implémentées
Et qu'il ne faut pas toucher.
Ça oblige donc qu'elles soient des classes abstraites ...

Mise à part le fait que de donner des classes abstraites pose le problème
Qu'on ne donne plus le choix de l'héritage aux suivants ...
Ça me pose un autre problème sur le contenu du code qui demande d'autres objets ...
J'aimerai donner une dll light ...

J'avais pensé à une Interface de "déléguation" Oo
En gros, je donne la possibilité aux gens de créer un composant
Qui sera inséré dans une classe de mon cru avec mais appels et tout et tout ...
Donc plus de classes abstraites et plus que des interfaces ...
Ça semble beau ...
Mais je risque pas de perdre le typage de mes composants ?
Je veux dire, j'aurais que des A et des B strict au final Oo
Ça pourrait poser problème ?

L'autre problème que je vois,
C'est que si j'ai une interface,
Le développeur ne peut pas utiliser une méthode sans l'implémenter =/
(ça devient dure à expliquer xD ... je vais mettre un peu de code pour éclaircir ^^)

Admettons que j'ai la classe A ainsi :
(je ne ferait qu'une classe pour simplifier ^^)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public abstract class A { public void meth1() { // utilisation/déclaration de plein d'autres classes // dont le développeur n'a pas d'obligation de connaitre }   public abstract void meth2(); }

---

Je pensais faire :

Code:

---

1 2 3 4 5

public interface IA { void meth2(); }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public class A : IA { IA deleg;   public void meth1() { // utilisation/déclaration de plein d'autres classes // dont le développeur n'a pas d'obligation de connaitre }   public void meth2() { deleg.meth2(); } }

---

Mais le soucis c'est que dans l'implémentation de IA,
On ne peut pas se servir de meth2() =/

Quelqu'un voit mon soucis ? =/
Et quelqu'un voit une solution ? ^^

J'ai tellement mal au crane que je suis sur que je rate quelque chose ...
Heureusement c'est bientôt le Weekend ^^

J'ai rien compris :aie:
Quel est le but concret?

Lol ^^
Je le pressentait ^^

Bon le but c'est que des gens puissent programmer d'autres composants
Ces nouveaux composants hériteront d'une classe abstraite
Car une partie du code est déjà écrite (et doit le rester ^^)

Le soucis c'est que dans ce code déjà écrit,
On fait allusion à d'autres classes qui ne devrait pas être visibles ...
Et donc, si je met ma classe abstraite dans une dll
(pour laisser aux gens la possibilité de faire de nouveaux composants)
Et bien je vais devoir ajouter les classes utilisées ...

Mais peut être que je me trompe Oo

Ensuite,
Tous les composants, déjà existants et ceux créés en extérieur,
Doivent se rejoindre dans une seule et même Factory.
Dans ton tuto, tu montres le mappage par fichier de configuration,
Mais ça défini que ce fichier est écrit en dur,
Et qu'il ne peut donc plus bouger ...

Comment faire pour y rajouter les nouveaux composants créés par la suite ?

Effectivement si tu fournis ta class abstraite dans une dll il y aura les classes dont elle dépend car il faudra que tu compiles ce projet sans erreur. Mais c'est compilé et puis tu controles l'accès aux classes et au méthode (public, private, proteced...) donc là par de problème du peux fournir cette dll avec plein de classes, le développeur ne verra que la classe abstraite. Et un problème de résolu.
Après les nouveaux composants il faut bien les développer, ils auront normalement un nouveau (à moins que tous les dév les appelles pareil dans le même namespace...) et pour qu'il soit utilisable il faut les charger.
Alors pour charger une classe d'un dll dynamiquement c'est pas compliqué mais faut chercher un peu...
En gros il faut le nom complet de la classe et pourquoi pas le chemin de la nouvelle dll (ou tu la mets dans le GAC), enfin du peux toujours parcourir un répertoire donner et faire de la réflexion sur les classe implémentant les classes abstraite A et B. Enfin si tu veux faire ça à chaud il faudra quand même trouver un moyen de notifier le programme pour qu'il recharge les définition de classe.
Tout ça c'est pour quel genre d'appli ?

Bon après avoir relu, je te suggère d'aller voir plutôt dans MEF! C'est adapté aux plugins et chargements à chaud.

Pour charger les nouvelles classes,
Ton lien précédant fonctionne niquel y a pas de soucis ^^

Si je mets tout dans la dll,
Le soucis c'est que ça me fait une dll béton Oo
Avec la quasi totalité de mon appli dedans Oo

J'ai voulu essayer une coquille vide ...
Mais pour ça il faudrait que j'arrive a changer l'appel d'une méthode =/

Je m'explique ^^

J'ai ma dll qui definit une coquille vide :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

namespace MyDLL { public abstract class IA { public virtual string meth1() { return default(string); }   public abstract string meth2(); } }

---

puis j'ai mon programme qui défini le véritable objet :

Code:

---

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 32 33 34 35 36 37 38 39 40 41

namespace TestDLL { public class A : IA { IA deleg;   public A(IA a) { deleg = a; }   public new string meth1() { // B ne doit pas être connu autre part que dans le programme return " A.meth1 call : " + new B().meth(); }   public override string meth2() { return deleg.meth2(); } }   // et le test ^^ class Program { static void Main(string[] args) { A obj; obj = new A((IA)AppDomain.CurrentDomain. CreateInstanceFromAndUnwrap( "plugins\\FirstPlug.dll", "FirstPlug.MyA"));   Console.WriteLine(obj.meth1()); Console.ReadLine(); Console.WriteLine(obj.meth2()); Console.ReadLine(); } } }

---

Et enfin un exemple de plugin ^^ :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

namespace FirstPlug { public class MyA : IA { public override string meth2() { return "MyA.meth2 call : " + meth1(); } } }

---

Le soucis c'est que le meth1() appelé par MyA.meth2()
Va chercher le code dans IA =/

L'appli est une gestion de flux de données (en gros)
En fait je sais pas si j'ai le droit d'en dire plus :?

Y a pas de code dans IA... c'est une interface...
Donc y a pas de problème :mrgreen:

Gestion de flux... et pourquoi ne par partir avec un outils qui sert à ça : ETL, AEI ou ESB. Ces truc sont déjà architecturé pour gérer ce genre de trucs.

Citation:

---

Envoyé par NicoL__

Y a pas de code dans IA... c'est une interface...
Donc y a pas de problème :mrgreen:

---

public abstract class IA
Elle a beau avoir un I devant son nom,
Cette classe n'est pas une interface,
Elle joue plutôt un pattern Façade.

Citation:

---

Envoyé par NicoL__

Gestion de flux... et pourquoi ne par partir avec un outils qui sert à ça : ETL, AEI ou ESB. Ces truc sont déjà architecturé pour gérer ce genre de trucs.

---

Ce n'est pas ce genre de flux non Oo
J'ai dit gestion de flux, car c'est comme ça qu'on me l'a vendu ^^
Mais c'est plutôt vague ^^

c'est le

Code:

---

1 2	public new string meth1()

---

qui entraine ce problème vaut mieux faire un override si tu veux utiliser le polymorphisme j'ai jamais utiliser new car ça entraîne plein d'erreurs.

Bon, j'ai tout modifié Oo
Ça semble fonctionner proprement Oo

MEF est super puissant ...
Mais un peu trop pour mon utilisation ^^
Il y a beaucoup trop de choses qui ne me servent pas
Donc je reste au plus simple ^^
J'ai gardé ma factory qui est utilisable avec des string (adieu les enums)
Maintenant elle contient d'autres factory ^^

J'impose à la création d'un nouveau plugin d'avoir une classe de type IFactory,
Qui me permet de remplir ma factory principale et à qui je délègue l'instanciation ...

Et j'utilise Unity pour régler mes problèmes de dépendances dans ma dll
Toutes les classes qui n'ont pas lieu d'être dans la dll sont instanciées via Unity ^^


Je marque comme résolu ...
Donc à la question "Interface de marquage et Enum en C#" ...
Ma réponse est :
Obliger de passer par une instanciation massive de petites classes ...
C'est fastidieux et bien dommage que .Net ne propose pas ce genre de chose.
Donc pour une utilisation simple, vaut mieux rester sur des string
Et de bien faire attention à ce qu'on écrit =/

Voila ^^
Si vous avez des questions sur comment j'ai fait pour la suite du problème,
N'hésitez pas à me demander dans ce thread ;)