Imposer une methode statique

Version imprimable

29/06/2011, 18h07
brachior

Imposer une methode statique

Bonsoir ^^

J'ai des objets Component qui possèdent plusieurs identifiants ID
(qui sont affectés à des objets internes à un Component)

Lorsque j'ai besoin de ces identifiants,
Le Component n'est pas encore créé (et il ne le peut/doit pas)
Je dois donc passer par quelque chose de statique ...

Le mieux serait une méthode statique dans chaque Component
Qui retournerait tous ses identifiants ...

Mais c'est pas possible (si ? :))
Car pour cela, il faudrait que cette méthode soit dans l'interface ...

Merci de m'aider ^^
Je suis ouvert à toutes les propositions ^^
29/06/2011, 20h55
nevaram

Salut,

par réflection tu peux appeler une méthode static sur chacun des objets, mais tu ne pourra imposer que cette méthode soit implémenté.

Je ne sais pas si tu as la main sur ces dit objets ?
29/06/2011, 21h19
Nathanael Marchand

Je pense que comme la dernière fois y'a un problème de conception à la base :D

Citation:

Le mieux serait une méthode statique dans chaque Component

Rien que cette phrase est magique car elle ne veut strictement rien dire! Une méthode statique est une méthode qui n'est pas une méthode d'instance il est donc impossible d'avoir deux objets avec une méthode statique qui dépendrait de l'objet. A vrai dire ma phrase ne veut aussi rien dire car une méthode statique est membre du type et non pas de l'instance. Enfin bref y'a un sacré méli-mélo entre classe/objet et statique/instance. Et comment peut on récuperer des attributs d'un objet si cet objet n'a pas d'instance?

Si c'est pour le même sujet que la dernière fois: applique des choses simples! La vie c'est pas le Xbox Live où il faudrait appliquer un maximum de patterns pour obtenir des trophées! :D

Note: y'a rien de méchant ni moqueur dans ce post hein
30/06/2011, 09h32
brachior

En fait, quand je dit «Le mieux serait une méthode statique dans chaque Component»,
Je ne parle pas d'une instance mais véritablement de la classe.

Un objet ObjA qui hérite/implémente Component n'aura que une seule implémentation,
Donc les identifiants en question seront définit une bonne fois pour toute ...
Qu'on instancie 1 ou 20 fois la classe, ça ne changera rien ...

C'est pourquoi un accès statique est possible ...

Pour ce qui est des patterns,
Oui j'en utilise beaucoup ... Non c'est pas pour faire joli ^^
Mais moi et la bidouille ... J'ai arrêté (du moins j'essaye au maximum ^^')

Les patterns (avec parfois quelques modifications mineures)
Répondent parfaitement aux attentes d'un logiciel,
Ils sont parfait pour maintenir une cohésion dans un logiciel
Et permettre son évolution simplement ...

Après j'ai pas eut beaucoup de cours à ce sujet ...
J'en aurai plus l'an prochain ...
Mais quand je vois les logiciels actuels
Et le temps que passe les gens à les débugguer ...
Je me dit qu'il est préférable de perdre du temps sur l'architecture,
Quitte à ralentir la productivité de la boite ...

@nevaram :
En fait, ceux sont des plugins,
Donc ce n'est pas moi qui les écrirais tous =/

En fait je cherche un moyen de récupérer des variables propres à une classe
Et que la personne qui écrit cette classe se rappel/sache qu'il le faut =/
30/06/2011, 09h47
nevaram

Citation:

récupérer des variables propres à une classe

Des attributs ne pourraient-ils pas faire l'affaire ?
30/06/2011, 09h50
nah666

Citation:

La vie c'est pas le Xbox Live

Mon monde s'écroule :(
30/06/2011, 10h00
brachior

Citation:

Envoyé par nevaram

Des attributs ne pourraient-ils pas faire l'affaire ?

J'y pensais justement ...
(j'en ai jamais fais, mais ça se rapproche des Annotations en Java ... non ?)
Le seul truc, y a moyen d'imposer ce mécanisme ?

Je pourrai essayer de faire un test de rechercher un champs/méthode statique spécifique
Par réflexion au sein d'un Component donné pour savoir s'il respecte ou non la "syntaxe" imposée Oo
Par exemple une dll des tests basiques que doit respecter un nouveau Component ...

Je sais pas ce que vous en pensez Oo
30/06/2011, 10h18
nevaram

A mon avis si c'est de la donné concernant ton plugin (le nom, un Guid,...) je pense qu'un attribut sur la classe est fait pour ça.

Au démarrage de l'appli tu cherches toutes les classes qui on l'attribut.
30/06/2011, 12h22
DonQuiche

Si les composants sont définis au sein des plugins, tu as deux possiblités : soit tu forces les plugins à enregistrer leurs composants manuellement, soit au chargement d'un plugin tu utilises la reflection pour le faire automatiquement (en ayant ajouté des attributs sur les classes).

Cela dit, tout ça semble peu élégant. Chaque composant-singleton est donc associé à un plugin et contient les informations du plugin. Quelle informations ? Pourquoi ton appli a t-elle la responsabilité de détenir ces informations ? Si ce sont des informations qui doivent être sérialisées, alors tes plugins devraient plutôt détenir cette responsabilité (réaction à un événement Serializing de l'application, ou implémentation d'une interface IPlugin avec méthode Serialize(Stream)).

Hum ...
Tu chamboules tout avec les noms ^^
Par "plugin" tu parles d'un composant (Component)
Et par "composant" tu parles d'identifiant ? :aie:

Enfin bon ^^
J'ai besoin de ces identifiants pour lier des composants entre eux,
Et je ne dois pas les instancier (les composants) ...
Les identifiants doivent donc forcement être instanciés de façon statique
Ou en extérieur du composant (ce qui me plait pas trop =/)

Je ne peut donc pas demander de le faire par le composant
(ce que tu appelles "l'enregistrement")

En règle général,
Chaque plugin comprend une factory qui se charge d'instancier un composant.
Donc un plugin contient 1..* composants ^^
(ça reste à définir par ma boite, c'est possible qu'ils préfèrent 1 plugin = 1 composant)

Les identifiants seront certes sérialisés car ils seront contenus dans une configuration.
Mais ils seront surement stocker sous forme de string ...
(je ne sais pas encore ^^)

Mon application a besoin de ces informations pour une IHM,
Lorsqu'on prend un composant, et qu'on veut le brancher sur un autre,
On a besoin de savoir les identifiants des entrées/sorties ^^

J'ai regardé du côté des Attributes ...
J'ai quelque chose de fonctionnelle
(pas tester à l'intérieur d'un plugin par contre ^^)

J'ai mes attributs :

Code:

1
2
3
4
5
6
7
8
9
10
 
    [AttributeUsage(AttributeTargets.Class)]
    public class MyPluginAttribute : Attribute { }
 
    [AttributeUsage(AttributeTargets.Method | AttributeTargets.Property)]
    public abstract class IDListAttribute : Attribute { }
 
    public class IDOutputListAttribute : IDListAttribute { }
 
    public class IDInputListAttribute : IDListAttribute { }

et des extensions pour mes tests :

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
    public static class MemberInfoExt
    {
        public static bool checkMethodPlugin(this MethodInfo mi)
        {
            return mi.ReturnType.Equals(typeof(IList<string>)) && mi.IsStatic;
        }
 
        public static bool checkPropertyPlugin(this PropertyInfo pi)
        {
            MethodInfo mi = pi.GetGetMethod();
            return mi.ReturnType.Equals(typeof(IList<string>)) && mi.IsStatic;
        }
 
        public static IDictionary<IDListAttribute, string> getMethodFromClassPlugin(this Type type)
        {
            IDictionary<IDListAttribute, string> _list =
                new Dictionary<IDListAttribute, string>();
            IOXPluginAttribute[] attrs = (IOXPluginAttribute[])type
                .GetCustomAttributes(typeof(IOXPluginAttribute), false);
            if (attrs.Length > 0)
            {
                foreach (MethodInfo method in type.GetMethods())
                {
                    IDListAttribute[] mattrs =
                        (IDListAttribute[])method.GetCustomAttributes(typeof(IDListAttribute), false);
 
                    foreach (IDListAttribute attr in mattrs)
                    {
                        if (method.check())
                        {
                            _list.Add(attr, method.Name);
                            break;
                        }
                    }
                }
 
                foreach (PropertyInfo property in type.GetProperties())
                {
                    IDListAttribute[] pattrs =
                        (IDListAttribute[])property.GetCustomAttributes(typeof(IDListAttribute), false);
 
                    foreach (IDListAttribute attr in pattrs)
                    {
                        if (property.check())
                        {
                            _list.Add(attr, property.Name);
                            break;
                        }
                    }
                }
            }
            return _list.Count > 0 ? _list : null;
        }
    }

30/06/2011, 13h14
DonQuiche

Citation:

Envoyé par brachior

Hum ...
Tu chamboules tout avec les noms ^^
Par "plugin" tu parles d'un composant (Component)
Et par "composant" tu parles d'identifiant ? :aie:

Non, je croyais que tes "composants" étaient des classes-singleton définies au sein des plugins, avec un composant par plugin, mais ne représentant pas le plugin lui-même : je pensais que ce n'était qu'un conteneur de données associé au plugin, sans comprendre pourquoi il était utilisé en-dehors. Et par "enregistrer un composant" je voulais dire "stocker quelque part une paire ID/composant".

Maintenant je voulais simplement vérifier si c'était une usine à gaz ou non mais impossible de faire ça avec les informations dont nous disposons. Le problème est que nous ne connaissons pas le rôle de tes composants, leurs responsabilités, pourquoi tu as besoin de les connecter ainsi par des identifiants plutôt que de bâtir un graphe d'objets (autrement dit pourquoi tu ne peux pas les instancier), etc...
30/06/2011, 14h05
brachior
Les composants communiquent entre eux par le biais d'entrées/sorties spécifiques
(une entrée A ne peut se brancher qu'avec une sortie B, ...)

Ils forment un graphe au final, mais chaque composant vient d'une dll ...
Le programme ne connait que les interfaces ...

En fait, un composant est explosé en 3 parties :
1. Le Corps : qui fait les opérations
2. Les Entrées : qui récupèrent et pré-traitent les données reçues
3. Les Sorties : qui reçoivent les données du Corps et préviennent les Entrées qui leurs sont associées
Je dois donc relier des Entrées avec des Sorties ...
Je le fais via une IHM (qui sera assistée par des fichiers de configuration)
Je dois par ailleurs pouvoir créer des fichiers de branchements
Qui ne doivent pas dépendre des instances.
Il ne faut pas que je sérialise des données contenues par des Entrées/Sorties
Et je dois pouvoir reconstruire la totalité d'un branchement via ce fichier
Sans pour autant l'instancier. (je dois pouvoir faire des tests au préalable)

Pour faire ça, j'ai besoin de savoir qu'elles sont les Entrées/Sorties d'un composant ...
Et la seule chose que je sais, c'est que leur nombre et leur type/id est fixés pour chaque "type" de composant ...
30/06/2011, 16h45
DonQuiche

Je te remercie mais j'ai malheureusement l'impression que nous n'arriverons à rien, que je n'aurais jamais assez de détails pour comprendre le comment du pourquoi de tel et tel choix. Mieux vaut donc que je ne t'assaille plus de questions.

Simplement, si par hasard tu as une correspondance entre interfaces implémentées par les composants et identifiants, mieux vaudrait sans doute utiliser directement les interfaces.

Par ailleurs, si ce qui t'empêche d'instancier les composants avant la création des interfaces est le fait que cette initialisation réclame certaines ressources lourdes, tu pourrais peut-être revoir ces composants pour séparer les responsabilités afin qu'ils puissent être instanciés plus tôt et qu'ils aient simplement la tâche d'allouer ces ressources tardivement, éventuellement par le biais d'autres classes, internes au plugin. Ou faire de tes composants des sommets d'un graphe chargé de la validation et de la construction du graphe réel. J'imagine que tu as déjà un tel graphe, la différence serait donc que les sommets seraient définis dans les plugins eux-mêmes.