Discussion :

[kineton]

Bonjour,

Je souhaiterai connaitre la meilleure manière pour déclarer des paramètres (constantes, structures...) globaux dans un programme en c#.

En c++ il suffisait de tout ajouter dans un fichier .h puis d'inclure ce fichier dans les sources qui le nécessitait.

Qu'est il recommandé de faire en c# ? Existe t il l'équivalent des fichiers h ?

La manière que j'ai utilisé est de déclarer mes structures et autres variables globales au début du fichier de ma form principale, puis pour y accéder depuis d'autres form j'utilise le mot clef using. Je ne sais pas si cette méthode est recommandée.

Merci pour vos lumières.

[Bluedeep]

Pourquoi veux tu les déclarer dans ta forme principale ? désolé, je ne comprends pas vraiment ton besoin.

[kineton]

Pourquoi veux tu les déclarer dans ta forme principale ? désolé, je ne comprends pas vraiment ton besoin.

En fait je me pose simplement la question de savoir comment (et ou) il est recommandé de déclarer ses variables globales dans une application winform en c#.

[Bluedeep]

D'accord.

Tout d'abord, il est assez rare d'utiliser des variables globales; cela traduit en général un (gros) défaut de conception. (le fait que tu débutes dans le langage ne rentre pas ici en ligne de compte, c'est valable pour tous les langages objets).

Si tu veux à tout prix en utiliser, tu peux par exemple créer une classe static, et mettre tes variables dedans.

Exemple

Code :

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

1
2
3
4
5
6
7
 
public static class MyVariables
{
public static int Variable1;
public static string Variable2;
// etc ....
}

[thelpi]

Salut.

Pour des variables utilisables dans tout le programme, perso j'utilise les paramètres Settings ( ton application => Properties => Settings.Settings )
et ça marche pas mal Bien sur ça ne résout pas ton problème pour les structs.

[B.AF]

[QUOTE=Bluedeep;4078349]D'accord.

Tout d'abord, il est assez rare d'utiliser des variables globales; cela traduit en général un (gros) défaut de conception. (le fait que tu débutes dans le langage ne rentre pas ici en ligne de compte, c'est valable pour tous les langages objets).
[CODE]

Alors ça, c'est complêtement faux.

Tu as un logiciel qui a 30 clients.
Pour ces 30 clients tu as 25 options dont l'accès dépend d'une clef d'enregistrement.

Autant les avoir globalement disponible pour toute l'application que de devoir à chaque poser la question.(surtout que la réponse à cette question posée n fois entraine la même réponse).

La vraie erreur d'architecture, c'est quand la croyance technique annihile le bon sens.

Après la FACON de le faire peut être un problème d'architecture.
Mais ça, c'est du code pur, pas de la conception applicative.


Enfin pour repondre à la question tu as plusieurs options :
- Les fichiers de ressources du projet, qui seront disponibles partout dans l'application
- Les fichiers de config qui seront disponible partout dans le projet
- Un singleton que tu initialises au démarrage, et donc disponible partout dans l'application
- Un context d'un moteur IoC quelconque qui agira comme fabrique d'nstance dont tu aurais besoin au démarrage.

-

[Bluedeep]

Alors ça, c'est complêtement faux.

Tu as un logiciel qui a 30 clients.
Pour ces 30 clients tu as 25 options dont l'accès dépend d'une clef d'enregistrement.

Autant les avoir globalement disponible pour toute l'application que de devoir à chaque poser la question.(surtout que la réponse à cette
question posée n fois entraine la même réponse).

Oui, ert alors ? a priori tu stockes tes options dans un singleton instancié avec les valeurs ad-hoc dépendantes de ta clef.