Où ranger ses constantes ?

Bonsoir,

Je débute dans les langages de programmation (J'ai surtout fait jusqu'à maintenant du HTML/CSS/SQL, avec très peu de php/javascript, que du web) et j'ai un peu de mal pour le moment avec les portées des variables.
Je code en ce moment un programme, et j'utilise des constantes dans celui-ci, je pourrais même à l'avenir créer des fonctions que je voudrais accessibles n'importe où dans mon code.

Me conseillez-vous de mettre toutes mes constantes, énumérations, fonctions static dans une même classe ? Je les mettrais donc dans une classe static comme static class Program, où juste dans le namespace ?

Merci d'avance !

Bonjour,

personnellement je mets toujours mes variables globales et constantes dans un fichier du genre Globals.cs , et les méthodes dans Tools.cs / Outils.cs .Les variables en static + const et les méthodes en static. Attention par contre a ne pas tomber dans la facilité et y fourrer un peu tout et n'importe quoi :).

Dans mon cas pour le moment je n'utilise que des énumérations.

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

using System; using System.Collections.Generic; using System.Linq; using System.Text;   namespace Poker { public enum PhasesName { BLINDS, PREFLOP, FLOP, TURN, RIVER, SHOWDOWN }   public enum Combinations { HIGH_CARD, ONE_PAIR, TWO_PAIR, THREE_OF_A_KIND, STRAIGHT, FLUSH, FULL_HOUSE, FOUR_OF_A_KIND, STRAIGHT_FLUSH, ROYAL_FLUSH } }

---

Puis-je les stocker comme cela ? Dans ce fichier-là je n'ai donc pas besoin des using ?
Il me semble que les énumérations se comportent comme des classes et sont static de base ?
Merci !

Bonjour.

Tout d'abord, oui, les énumérations remplacent souvent avantageusement les constantes et tu as très bien compris comment les utiliser. En revanche c'est bien un type mais pas statique puisque tu peux typer des variables avec (voir exemple). Et même si les identifiants déclarés dans l'énumération se comportement comme des champs statiques, une instance de ce type a aussi accès aux méthodes d'instance héritées de "object" : ToString et GetHashCode.

Code:

---

1 2	Phases phase = Phases.Blinds; Console.WriteLine(phase.ToString());

---

Note qu'on n'a pas besoin d'ajouter un suffixe "Names" ou "Enum" au nom du type, le pluriel et la majuscule au début sont suffisamment parlants pour identifier une énumération au premier coup d'oeil. Du coup cela dispense aussi d'utiliser des majuscules. Et puis après tout, quand tu écris ce code, tu veux exprimer l'entrée dans la phase "blinds". Insister sur le fait que Blinds est une constante en le mettant en majuscules ne fait que détourner l'attention du lecteur (ton futur toi).


Si toutefois tu avais besoin à un moment d'une constante traditionnelle (ou d'une variable readonly), il est préférable de la stocker là où tu en as besoin. Autrement dit si une constante n'est utilisée que par une fonction, mets-la dans cette fonction. Si elle n'est utilisée que par une classe, mets-la dans cette classe. Et si vraiment tu as besoin de partager une constante entre plusieurs classes, mets-la à l'endroit où ça semble le plus logique (exemples : Int32.MaxValue, Path.PathSeparator, etc)

D'accord pour le suffixe Name, c'est vrai que ça peut alléger le code je l'enlèverai. Par contre pour les majuscules je fais ça par habitude, pour les constantes, de tout de façon ça ne change pas grand chose.
C'est vrai que le "_phases.Add(new Phase(_phases.Last().name + 1));" pour passer à la phase suivante c'est très pratique !

Du coup j'ai également une classe phase qui est la seule à utiliser ce type: "private PhasesName _name;" et une classe game qui contient une liste de phase, seul class dans laquelle j'utilise une phase. Me conseilles-tu de mettre l'énumeration dans la classe phase dans ce cas ?

Sinon je rajouterais une question. Un ami qui programme un peu de temps en temps m'a conseillé d'encapsuler mes propriétés de classes de cette façon:

Code:

---

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

private PhasesName _name; public PhasesName name { get { return _name; } set { _name = value; } }

---

Et d'utiliser le "_" quand j'utilise la variable dans sa classe. D'après lui ça me permettrait à l'avenir si j'ai besoin de rajouter des actions au getter ou au setter des mes propriétés de faciliter la chose et ne faisait pas de C# je crois qu'il voulait juste s'assurer que j'encapsule bien mes propriétés. Est-ce vraiment nécessaire sachant que je ne vais pas forcément rajouter d'instructions ? Autant le faire en temps voulu si j'en ai besoin ? Comment les déclarer de façon plus courte tout en les protégeant ? D'ailleurs j'applique l'encapsulation mais je ne comprends pas la nécessité, je sais que théoriquement on l'utilise pour protéger nos propriétés mais j'avouerais que j'aurais bien besoin d'un exemple pratique, pour moi il suffit juste de faire attention et étant assez borné et curieux j'aime savoir pourquoi je fais les choses :D

Merci d'avance !

Citation:

---

Envoyé par Knightdead

Du coup j'ai également une classe phase qui est la seule à utiliser ce type: "private PhasesName _name;" et une classe game qui contient une liste de phase, seul class dans laquelle j'utilise une phase. Me conseilles-tu de mettre l'énumeration dans la classe phase dans ce cas ?

---

Si Phase est la seule à référencer Phases, oui. Mais puisque ta propriété Name est publique j'en déduis que Game utilise Phases bien qu'elle-même ne stocke pas de données de ce type. Donc non.

Citation:

---

Un ami qui programme un peu de temps en temps m'a conseillé d'encapsuler mes propriétés de classes de cette façon:

---

Ouhlà, non. Mais je sais pourquoi ton ami t'a conseillé ça. La réponse est en quatre parties :

a) Pour une application, peu importe que tu aies un jour besoin de getters/setters non triviaux: si demain tu as besoin de transformer un champ en propriété, tu n'as rien de spécial à faire pour que ton code continue à fonctionner après ça. Le compilateur générera un binaire différent (avec un appel de méthode au lieu d'une simple lecture de champ) mais ça on s'en fiche. Si en revanche tu créais une bibliothèque à destination d'autres personnes, leur code à eux devrait être recompilé, ils ne pourraient pas simplement utiliser leur application telle quelle avec la nouvelle version de ta biblio, c'est pour ça qu'on entend souvent ce conseil. Pire : si l'un d'entre eux utilisait l'introspection (reflexion) pour rechercher un champ "Nom", demain ils ne le trouverait plus et il lui faudrait donc modifier son code source pour chercher une propriété à la place !

b) Beaucoup d'outils du framework ne fonctionnent qu'avec les propriétés : la sérialisation XML, la liaison de données WinForms/WPF, etc. Mais là encore, puisque ton code n'est que pour ton usage, si demain tu as besoin d'une propriété tu feras ce changement. En attendant je te recommande plutôt le principe Yagni (you ain't gonna need it == tu n'en auras pas besoin). Là aussi les choses seraient différentes si tu créais une bibliothèque à destination d'autrui.

c) On voit souvent ce conseil et il est toujours aussi infondé. A mes yeux c'est surtout une forme de dogmatisme voire de puritanisme.

d) Si vraiment tu tiens à coller des propriétés partout, il y a les accesseurs automatiques de nos jours :

Code:

---

public PhasesName name { get; set; }

---

Citation:

---

Et d'utiliser le "_" quand j'utilise la variable dans sa classe.

---

Concernant la notation, dans le framework les champs privés sont en pascalCase (minuscule au début), les propriétés et les types en CamelCase (majuscule au début). Suivre cette convention permet d'avoir un code homogène entre ta production et le framework. Du coup l'underscore ("_") n'est pas nécessaire (puisque Name désigne la propriété et name le champ) mais il peut éviter une confusion suite à une manipulation rapide ou une lecture peu attentive ("Name = name" dans le constructeur == gare à la casse). Personnellement je préfère sans.

D'accord merci pour tes explications, j'ai bien compris.
Je posterai à nouveau si j'ai besoin d'explication dans le futur.

Je te souhaite une bonne journée !