Discussion :

[BlackTutu]

Bien le bonjour,

Je m'adresse à vous parce que cela fait un petit moment que je n'ai pas développé en C#, et que pour me remettre un peu à niveau je me suis amusé à faire une petite application dans ce langage, sauf que je remarque certaines petites choses qui me contrarient, que je ne comprend pas (plus?) ! La plupart du temps je trouve des réponses/solutions à mes questions/problèmes sur le net et assez régulièrement sur ce forum.

Aujourd'hui, je suis confronté à un nouveau problème qui me pose quelques difficultés, c'est un cas assez précis et je ne trouve rien sur la toile qui pourrait m'aider, c'est donc tout naturellement que je me suis inscrit sur ce dit forum afin de vous y poser ma question.

Le cas est assez simple, je définit d'une classe abstraite qui dispose de 3 variables statiques et 2 méthodes (statiques également) traitant sur ces variables, héritée par trois autres classes. Mon but, bien évidemment, est de pouvoir définir des valeurs différentes à ces variables selon la classe que j'utilise. Pour initialiser ces fameuses variables (qui commencent à me prendre la tête !), j'ai définit des constructeurs statiques donnant des valeurs différentes dans mes trois classes. Le hic, c'est que ces trois classes verront à coup sûr les valeurs de leurs variables être égales. Pour être plus clair, les valeurs des variables de ces trois classes vaudront celles de la dernière classe ayant exécuté son constructeur statique!
Déjà, en soi, je trouve cela aberrant que des variables statiques héritées ne puissent pas être différentes selon la classe qui en héritent, même si, puisqu'elles sont statiques, elles pointent finalement vers celles de la classe mère. Cela signifie simplement que l'héritage de variables statiques est complétement superflues, ce qui est dommage. Mais pour le coup, je ne vois pas comment résoudre mon cas. J'aimerais éviter d'avoir à implémenter mes variables statiques dans chaque classe juste parce que leurs valeurs diffèrent, ainsi que leurs méthodes statiques qui seraient identiques dans chaque cas.

J'ai essayé plusieurs méthodes pour essayer de m'en sortir, toutes aussi vaines les unes que les autres (je m'en rendais à chaque fois compte en les mettant en application), aussi je me tourne vers vous, en espérant (sans en avoir le moindre doute) que vous ayez une solution à me proposer.

En espérant avoir été clair, merci d'avance de vos futures réponses.

[AJemni]

Bonjour,
Quelle est l'utilité d'ajouter static aux variables et aux methodes et au constructeur?

[Guulh]

C'est peut être possible dans d'autres langages (me semble avoir vu que Delphi avait quelque chose qui y ressemble), mais en .Net les notions de "static" et d'héritage sont orthogonales. Pourquoi as-tu besoin de rendre ces membres statiques ? Et comment espères-tu les faire hériter, puisque par définition l'appel d'un membre statique nécessite de connaître statiquement (c'est à dire dans ton code, pas au runtime) le type dont on appelle une méthode ?

Si tu veux faire de l'héritage, ne fais pas de méthode statique.

Et le constructeur statique n'a de constructeur que le nom; ce n'est qu'une méthode dont on est sûr qu'elle est appelée avant toute référence à la classe (c'est plus compliqué que ça mais là n'est pas la question), et n'a pas sa place dans une classe "classique", qui a vocation à être dérivée.

[BlackTutu]

Merci pour vos réponses aussi rapides.

Les constructeurs statiques dont j'ai parlé ne sont pas dans la classe mère abstraite mais dans les 3 autres, et sert à être sûr que les variables soient initialisées avant toute chose.
Presque toutes les méthodes de ces classes font des traitements sur ces variables dont la valeur n'est pas modifiée en fonction de l'instance, c'est pourquoi il me parait logique qu'elles soient statiques.
De même, les méthodes mises en statiques doivent pouvoir être appelées non pas en fonction d'une instance de classe mais depuis la classe elle-même, d'où l'intérêt qu'elles soient statiques également. Ces méthodes font le même traitement qu'importe la classe dans lesquelles elles se trouvent, c'est pourquoi j'ai jugé préférable de faire hériter ces classes d'une autre qui les implémente, afin d'éviter la redondance de code et d'être sûr que lorsque j'utilise ces classes je puisse appeler ces méthodes.
Les variables sont du coup héritées également, car elles sont nécessaires au traitement de ces méthodes, la classe abstraite me renverrait une erreur si elle ne les possédaient pas, et de la même façon que les méthodes, je veux être sûr qu'elles se trouvent dans les classes héritant de ma classe abstraite.

Décidément ça coince ça coince!

[Guulh]

Presque toutes les méthodes de ces classes font des traitements sur ces variables dont la valeur n'est pas modifiée en fonction de l'instance, c'est pourquoi il me parait logique qu'elles soient statiques.

Oui mais si tu veux que des classes filles puissent changer ces valeurs, tu dois les rendre abstraites (ou virtuelles).

Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class Carré
{
  public int Calculer()
  {
    return x * x;
  }
  protected abstract int x { get; }
}
 
class CarréDeHuit : Carré
{
   protected override int x { get { return 8; }
}

De même, les méthodes mises en statiques doivent pouvoir être appelées non pas en fonction d'une instance de classe mais depuis la classe elle-même, d'où l'intérêt qu'elles soient statiques également.

D'où te vient cette contrainte ?
Tu remarqueras, on observant le framework .Net, que rares sont les classes qui proposent beaucoup des méthodes statiques et sont en plus héritées. Les classes statiques représentent des constantes de l'appli / des constantes tout court, comme par exemple la config de l'appli, les infos sur le système, les opérations mathématiques, ... Bref des catalogues de propriétés et de méthode hors contexte, où l'héritage n'intervient pas.

Il faudrait voir ton code. Il y a de fortes chances que ton besoin soit simple, mais que ne connaissant pas de meilleure solution tu te lances dans une impasse (ce qui est normal hein, j'arrête pas, c'est au pied du mur que l'on voit le mieux le mur )

[BlackTutu]

Le problème c'est que je ne peux pas les mettre "abstract" tant qu'elles sont statiques.

Effectivement, j'ai de plus en plus l'impression d'être face à une impasse, c'est pourquoi je vais révéler un peu plus l'objet de l'application.

Il s'agit, en réalité, d'un petit programme dans lequel on entre des numéros d'une roulette de casino, afin que certaines statistiques soient faites et qu'il propose un conseil de jeu (ce n'est pas très élaboré, les conseils se limitent aux coups dont la probabilité est d'un demi, c'est à dire la couleur, la parité et la taille). Je dispose donc d'une classe "Numéro" et d'une autre "ListeNuméros" qui contient entre autre une collection de "Numéro". La classe "Numéro" contient 3 références d'instance vers les classes "Couleur", "Parité" et "Taille". Ce sont ces classes qui contiennent les attributs statiques "PROPRIÉTÉ1" et "PROPRIÉTÉ2", qui doivent valoir respectivement "ROUGE" et "NOIR", "PAIRE" et "IMPAIRE" et "GRAND" et "PETIT", et une variable d'instance qui vaut une de ces variables statiques. Les méthodes abstraites comptent, à partir de la classe "ListeNuméros" le nombres de "Numéro" ayant pour référence des instances qui valent la propriété passée en paramètre.

Je ne sais pas si j'ai été assez clair, en tout cas en écrivant ces lignes, l'impasse se lève. Il est évident que je fais fausse route depuis le début. C'est la classe "ListeNuméros" qui est censée faire le comptage, et non les trois classes. Je suppose que vous me confirmerez ce dernier avis?

[Nathanael Marchand]

C'est pas plus simple de passer par des enumérations Couleur, Parité et Taille?

[BlackTutu]

Le professeur qui m'a enseigné ce langage m'a appris à toujours éviter le type "enum" dans la mesure du possible. Pour lui c'était un peu, pour des raisons obscures ou que j'ai oublié, une aberration de voir cela dans ce langage.
De plus, les classe "Couleur" et "Taille" disposent de méthodes qui leurs sont propres, mais qui, je l'accorde, n'y ont pas trop leur place, puisqu'elles me revoient respectivement une couleur et un style de police pour de l'affichage.
Enfin, je voudrais sérialiser mes classes, or le type "enum" n'est pas sérialisable.

[Nathanael Marchand]

Le professeur qui m'a enseigné ce langage m'a appris à toujours éviter le type "enum" dans la mesure du possible. Pour lui c'était un peu, pour des raisons obscures ou que j'ai oublié, une aberration de voir cela dans ce langage.

Ah? Soit. Cela dit, c'est quand même pas mal utilisé dans .Net

De plus, les classe "Couleur" et "Taille" disposent de méthodes qui leurs sont propres, mais qui, je l'accorde, n'y ont pas trop leur place, puisqu'elles me revoient respectivement une couleur et un style de police pour de l'affichage.

A la limite, des méthodes d'extension suffisent.

Enfin, je voudrais sérialiser mes classes, or le type "enum" n'est pas sérialisable.

Fichtre! Encore heureux que si Une enum est généralement représenté par un entier derrière. Ca fait juste en sorte que cet entier ait une gueule un peu plus sympa
Mais sisi je te rassure, on peut sérialiser un enum!
http://msdn.microsoft.com/fr-fr/libr...attribute.aspx

[BlackTutu]

Ah? Il me semblait pourtant avoir vu ça en cours, et même avoir eu des soucis de sérialisation lorsque j'avais utilisé des Enum dans le cadre d'une autre application. Et bien soit, je vais mettre mes a priori de côté et utiliser des Enum. il est vrai que lors de la conception de mon application je m'étais fais la réflexion que des classes ne me paraissaient pas vraiment appropriées pour ce cas, mais j'étais quand même resté sur cette position.

Je vais tester cette option (pas ce soir ça fait un peu tard), mais dès que j'aurais un peu le temps de m'en occuper, et je repasserais ici mettre le topic en "résolu" si je ne vois pas de souci dans le cadre du programme.

En tout cas merci à toi pour tes conseils, ainsi qu'à Guulh pour les siens!

[Guulh]

Ah, donc tu es étudiant... Tu me permettras de laisser parler l'expérience ?

• Tu diras à ton prof que c'est un couillon. Un certain nombre de choix de designs dépendent de la taille et de la maintenabilité attendue d'un projet, et il peut être préférable de recourir à des tas de classes filles plutôt qu'aux enums, surtout si on est un ayatollah de la POO (comme ceux dénoncé dans ce rigolo article) aux dépends des autres paradigmes; mais dans ton cas, il serait bien bête de te passer des enums. "Couleur" n'a pas à être une classe, puisque c'est juste une caractéristique; une couleur ne fait rien. Elle est, c'est tout (on dirait du Van Damme )
• Dès que le projet dépasse le cadre du proto, il est bon de le séparer en couches. Donc là tu aurais des objets / des enums dans la couche business, comme "Carte", "Couleur", etc, ... ; dans ta couche UI, tu aurais un objet avec une méthode du style GetFontFor(CardColor c). La police ne concerne que l'apparence de ton appli, n'est ce pas ? Elle n'intervient pas dans tes calculs statistiques

[BlackTutu]

En fait j'étais étudiant l'an dernier, maintenant j'ai mon diplôme et me suis trouvé un CDI. Seulement mon patron est un vieux de la vieille qui ne veut pas entendre parler de POO, c'est la raison pour laquelle je me suis trouvé une petite application à développer pour ne pas perdre la main (de ma propre initiative et dont ce professeur n'a jamais entendu parler).

Ce professeur était brillant, j'en ai eu quelques uns qui m'ont enseigné l'informatique, aucun n'arrivait à la cheville de celui-ci, c'est pourquoi je ne lui répéterais pas ce que tu as dit

Je me suis peut-être avancé sur ce qu'il a dit des enums, j'avouerais que certains matins j'avais quand même du mal à ne pas confondre les cours avec les méandres de mes rêves (qu'il est bon parfois d'être étudiant pour finir ses nuits caché derrière son ordi), mais il me semble bien qu'il ne préconisait pas trop cette pratique, enfin il me semble, j'ai peut-être confondu avec mon propre avis, il est vrai que, pour une raison brumeuse, je n'aimais pas trop les utiliser.