[C#] Acceder a des informations d'une classe fille dans une methode static

Bonjour,

J'ai une classe A et une classe B.
La classe B hérite de A.
j'aimerai dans une méthode static défini dans la classe A acceder a des informations défini dans la classe B.

Apres plusieurs essais je n'arrive pas a grand chose de bien concluant.
L'impossibilité d'overrider les membres static est vraiment ... :?

Un exemple de ce que j'aurai voulu faire : faire un GetType() sur l'objet de class B dans ma méthode static de A.
J'ai reussi a le faire avec un généric :

Code:

---

1 2 3

class A<T> where T: new()   class B : A<B>

---

ensuite je fais un

Code:

---

1 2	T obj = new T(); obj.GetType();

---

Bon apres GetType() c une methode d'objet mais c une valeur arbitraire que j'utilise comme ID je peux mettre un ID en dur quelque part dans B, ca serai pas plus mal.

Des idées ?

Salut,

j'ai pas trop compris l'histoire du GetType() (apparement une ID generée a partir du type concret de l'objet ?), mais tu peux essayer avec un membre abstrait, genre :

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

class Program { static void Main(string[] args) { Trace.WriteLine(A.Truc(new B())); Trace.WriteLine(A.Truc(new C())); } }   abstract class A { public abstract Type ID { get; }   public static string Truc(A a) { return a.ID.ToString() ; } }   class B : A { public override Type ID { get { return this.GetType(); } } }   class C: A {   public override Type ID { get { return this.GetType(); } } }

---

Si je n'ai rien compris (ce qui est bien possible), pourrais tu donner plus d'infos ? =)

Bon ça va etre beaucoup plus clair si je donne le "but" de la maneuvre

Voici ma classe "A" :

Code:

---

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

public abstract class Controller<TController> where TController : Controller<TController>, new() {   public static TController Current { get { TController controller = new TController(); string controllerKey = controller.GetType().ToString();   if (HttpContext.Current.Session[controllerKey] == null) { HttpContext.Current.Items[controllerKey] = controller; } return (TController)HttpContext.Current.Session[controllerKey]; } } [...] }

---

et ma classe "B"

Code:

---

1 2 3 4 5

public class SearchController : Controller<SearchController> { [...] }

---

C'est du pseudo singleton sur le context http a l'aide d'une clef unique. Actuelement j'utilise le GetType de la classe mais faire un new a chaque current (une 15 ene de fois par requete alors qu'un seul suffirai) ce n'est pas top du tout

Pas besoin d'instancier l'objet pour connaitre la classe, tu peux passer plus simplement par un typeof(T), essaie peut etre comme ceci :

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

public abstract class Controller<T> where T : Controller<T>, new() { public static T Current { get { Type t = typeof(T); T value; if ((value = HttpContext.Current.Items[t.ToString()] as T) == null) { value = new T(); HttpContext.Current.Items[t.ToString()] = value; }   return value; } } }   public class SearchController : Controller<SearchController> {   }

---

En esperant que cela t'aide.

ah oki je pensais pas que ca marcher sur les generiques ... bien que ça ne resout pas ma question originel ça répond a pas mal de question à propos des generiques ça rend mon code bien meilleur merci :)

Et juste pour info, si tu te poses la question de savoir comment dans la classe A (ta classe mère) avoir accès aux membres de la classe B (classe fille), tu es en train d'implémenter un anti-pattern.
Une classe mère ne doit pas avoir connaissance de ses enfants.

La proposition de SirJulio est effectivement plus clean.

Le but de l'héritage de classe c'est de factoriser au maximum le code pour ne pas a avoir a réécrire le code dans la classe fille et dans ce cas je n'appellerai jamais le membre static sur la classe mere mais bien sur la classe fille

Citation:

---

Envoyé par anthyme

Le but de l'héritage de classe c'est de factoriser au maximum le code pour ne pas a avoir a réécrire le code dans la classe fille et dans ce cas je n'appellerai jamais le membre static sur la classe mere mais bien sur la classe fille

---

Le but aussi est de ne pas avoir à réécrire le code de la classe mère quand on crée une nouvelle fille.

mais je ne dis pas le contraire ... :roll:

ce queje cherchait c pas de modifier la classe mere tout le temps mais d'avoir un systeme qui force une certaine implémentation dans la classe fille un peu comme un

Code:

---

abstract member {get;}

---

mais en statique,

c'est tout ...

Citation:

---

Envoyé par anthyme

mais je ne dis pas le contraire ... :roll:

ce queje cherchait c pas de modifier la classe mere tout le temps

---

-->

Citation:

---

Envoyé par anthyme

j'aimerai dans une méthode static défini dans la classe A acceder a des informations défini dans la classe B.

---

Ben ça, ça induit de modifier la mère en fonction de la fille...

Citation:

---

mais d'avoir un systeme qui force une certaine implémentation dans la classe fille un peu comme un

Code:

---

abstract member {get;}

---

mais en statique,

c'est tout ...

---

Il faut que tu sois plus clair, je n'ai pas compris ce que cet exemple "force".

Je posterai un exemple ce soir ;)

Sinon cela "force" dans le sens ou si tu ne le redéfini pas dans une sous classe tu aura une erreur

Bah justement le mot clé abstract est la pour cela non ?
Faire de l'abstract statique cela n'a pas de sens.
Toutes méthodes statiques de ta classe mère ne doivent pas être modifié par les classes filles.
Si tu constate que ta méthode doit être modifié par la fille, alors la méthode ne doit pas être statique. Tu peux donc faire de la surcharge :)
Si tu as besoin que ta méthode soit à la fois statique et surchargeable par les classes filles, c'est que tu as une erreur dans la conception de ton programme.

Je vois pas en quoi c'est une erreur de conception ... de plus on peu tres bien redefinir une methode static via les mot clef "new static"

exemple d'utilisation :
une methode static de création d'objet (type singleton) a redéfinir dans des sous classe si on veux une portée différente
tant qu'on aura pas de mot clef "return" dans le constructeur C# (comme d autre langages) on ne pourra pas se passer d'une methode static...

Bah du fait que static c'est une méthode définie une fois pour tout le programme. Donc définir une méthode statique dans une classe, puis se rendre compte dans la classe fille on aurait besoin de la modifier peut révéler d'une erreur de conception. Elle peut être simple comme erreur, du genre la méthode n'aurait pas du être définis comme statique.
Considère qu'une méthode définie comme statique est comme "un type".
Je ne vais pas t'expliquer cela car il y a des personnes présentent sur ce forum qui saurait mieux l'expliquer que ce que je pourrais faire.

En gros bref ce que j'ai cru comprendre sur la discussion c'est que tu étais embete de ne pas pouvoir surchargé dans tes classes filles la méthode static mère et que tu voulais obligé toute classe héritant de la classe mère d'implementer cette méthode.
Alors ce que je me dit : pourquoi ne pas enlever le static de ta méthode et le remplacer par abstract ?
Et j'en etais arriver à la conclusion que si tu ne pouvais pas faire cela il y avait peut être un problème de conception. Maintenant je ne connais pas ton programme, donc je ne sais pas. Ce n'est aps une critique mais une alerte du genre : Attention, il y a peut être un problème. C'est pour obliger les gens à revoir certain truc et s'assurer qu'il n'y a pas de problème. Parce que lorsque tu es plongé dans le code, tu ne t'aperçois pas forcement qu'il y a une couille dans la conception et tu essaye de résoudre le problème courant par une possibilité du langage. Cela m'est arrivé récement et j'ai du faire du refactoring sur mon programme :aie:

Citation:

---

Envoyé par anthyme

Je vois pas en quoi c'est une erreur de conception ... de plus on peu tres bien redefinir une methode static via les mot clef "new static"

---

Je ne suis pas d'accord...

Le "new" ne redéfinie pas, il cache...

Alors ok, tu peux faire :

Code:

---

1 2 3 4 5 6 7 8 9 10

public class A { public static void Hello() {} }   public class B : A { public new static void Hello() {} }

---

Et puis quoi ? tu vas pouvoir faire A.Hello() ou B.Hello()...super ! Intérêt très limité et aucun rapport avec le fait que B hérite de A puisqu'on ne travaille pas sur des instances.

apres relecture du topic je vois qu'on est parti loin et effectivement quand je dis acceder a des methode des sous classe d'une classe mére ce n'est pas en "découvrant comme par magie" :mouarf:

c'est bien en passant par le généric (qui est la classe fille passé a la classe mère) que j'essai de faire ce patern ...

je reprend mon controller :

Code:

---

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

public abstract class Controller<TController> where TController : Controller<TController>, new() { protected Dictionary<Type, List<Object>> views;   public static TController Current { get { string controllerKey = typeof(TController).ToString(); if (HttpContext.Current.Items[controllerKey] == null) HttpContext.Current.Items[controllerKey] = new TController(); return (TController)HttpContext.Current.Items[controllerKey]; } } }   public class SearchController : Controller<SearchController> {   }

---

imaginon maintenant que je veulent parametrer la méthode de récupération (changer la clef, stocker le controller en session au lieu d'application, ou autre ...) mais seulement pour mon search controler.

si j'avais pu faire mon current en methode non statique, j'aurai pu créer des propriétés de ce type :

Code:

---

1 2	abstract string indexKey {get;} abstract monEnumCotrollerStoring controllerStoring {get;}

---

mais la mon current est static et il ne pourra pas acceder a ce genre de propriétés ... d'ou mes questions

dans un autre topic (d'ailleur ca commence a faire redondant la) ou c plus acces sur l acces au methode static sur un Generique on en été arrivé a un seul solution : un typeof sur le généric et un coup de réflexion...

Apres si vous avez de meilleur methode je suis tout ouïe ;)

Un petit truc qui n'a pas été évoqué dans le thread : quand on a des problèmes de méthodes à faire supporter par des classes, en dehors de abstract, on peut aussi et plus simplement utiliser les interfaces.
Du coup la classe mère peut tester si une instance, classe fille ou non, supporte ou non l'interface en question.
Les interfaces offrent souvent des solutions simples à des problèmes qui deviennent compliqués avec le seul héritage.
A y penser dans le problème évoqué ici en tout cas.

+1
L'interface pourrait être la solution et ce serait plus simple à utiliser.

Mais je me demande quand même pourquoi ton controleur est statique ?
Juste une question de simplicité pour être utilisable par d'autre classe ?

Je répéte encore une fois, une méthode statique est statique et ne doit pas être modifié. Si tu as besoin de la modifier, alors il ne faut pas la mettre en statique.

en réalité son probleme n'est pas stupide j'ai exactement le meme...

je voudrais règler le probleme de l'instanciation dans une fonction statique de la classe mère... car j'"apporte des TAS de controles qui sont propres à la classe mere certes mais par question d'esthétisme et surtout de fénéantise...

PK REECRIRE 15x fois la meme chose ?

personnellement pour moi ca change rien suis un afissionado de la reflexion... donc... mais bon...

non son probleme n'a rien de stupide, je voudrais une méthodes statique d'instanciation unique et visible dans le code de la classe mere qui controle les assertions de base et qui engendre bien l'objet que je souhaite et pas la mere vu que chez moi elle est abstract vu qu'elle sert de modele.

bon j'ai utilisé la méthode proposée par sirjulio mais on aurait pu envisager que cela doit règler autrement.

'Lut,

bah a ce moment la, autant passer par une factory externe à ces classes qui s'occupera d'instancier le bon objet, apres libre à toi de le parametrer. Mais, AMHA, la reflexion, ca peut vite etre le gouffre à perf, car on peut faire beaucoup de choses avec mais ca se paye (et plutot cher d'ailleurs). Enfin bref, la reflexion, tant que j'ai une autre solution (quite à remanier un peu le design) je prefere ne pas l'utiliser (Bon faut voir aussi sur la frequence d'utilisation, si la methode est appelée une fois au debut du prog, ca passe, si elle est appelée tres souvent, ca risque de couter cher.)

tout dépend pourquoi aussi :)
disons qu'elle ne me sert surtout qu'au chargement de modules, chargements et instanciations d'objets métiers spécifiques, bien particuliers ...

enfin j'en suis quand meme un afisionados dans la mesure où pour la serialisation/deserialisation xml ca reste particulierement utile... meme si je dois bien l'avouer en terme de performance on a vu mieux :)

Je reste sur ma position -> Une méthode statique ne doit pas être modifié.

C'est juste une question de respect des règles pour faciliter la maintenance.
Imaginer le gars qui reprend votre code, il voit une méthode statique, donc il la pense "vrai" et que toutes fonctions l'utilisant va faire ce qu'il y a dedans. Si maintenant vous arriviez par je en sais quel moyen à rendre la méthode static surchargeable et modifiable dans des classes filles, vous allez lui compliquer la tache.

Et imaginer que cette personne c'est vous 1 ans après avoir écrit votre programme une fois que vous avez oublé comment vous l'avez fait :) .

Bref faire sa tambouille et ne pas respecter le rôle de chaque composant, chaque entité, provoque des problèmes de maintenance.