Variable "statique"Résolu

Question

Bonjour, 

Je sors d'une très longue période de programmation en VB6 pour passer en C# (il était temps...)

En VB, il est possible de déclarer une variable "static" dans une fonction qui ne l'est pas. La caractéristique de ce type de variable est qu'elle garde sa valeur entre deux appels à la fonction. C'est très pratique par exemple pour gérer un drapeau qui signale que la fonction a déjà été appelée une fois et que certaines initialisations ne sont plus nécessaires.
Cela évite d'avoir une tapée de variables déclarées au niveau de la classe, qui ne servent que dans une fonction.
De mémoire (c'est très très vieux), il existait la même chose en langage C.

En C#, je n'ai pas réussi à trouver l'équivalent : le modificateur static est refusé par le compilateur, que la fonction soit statique ou pas, et que la classe elle-même soit statique ou pas.

Quelqu'un sait-il comment conserver la valeur d'une variable d'une fonction entre deux appels, sans avoir à déclarer cette variable en dehors de la fonction, et sans générer une usine à gaz ?

Whismeril · Answer

Bonsoir

ça n'existe pas.

D'un autre coté

int monEntier = 0;

public void ModifierEntier()
{
    monEntier++;
    // etc...
}

 
C'est pas vraiment ce que j'appelle une usine à gaz.

MGD Software · Answer

Certes, comme cela, ce n'est pas une usine à gaz.

Mais si j'ai cinquante fonctions qui ont chacune deux trois variables qui devraient être internes, ça devient bien une usine à gaz.

Et quid de la fameuse encapsulation, si chère aux programmeurs modernes ??
On cherche à tout prix à réduire la visibilité des variables au minimum, pour une meilleure lecture et compréhension du code.

Ça ne va pas dans le bon sens. Le langage C et plus tard VB étaient plus performants à ce niveau. Pour un peu, on se retrouverait au niveau de MS-Basic (1975), dont toutes les variables étaient globales.

Mais bon, on va faire avec, puisqu'on n'a pas le choix.

@+

Whismeril · Answer

Bonsoir


Et quid de la fameuse encapsulation, si chère aux programmeurs modernes ?? 
On cherche à tout prix à réduire la visibilité des variables au minimum, pour une meilleure lecture et compréhension du code. 
 
L'encapsulation c'est par rapport à l'extérieure de la classe, et ça n'est pas une histoire de lecture de code, mais de droits d'accès et de constance de "signature".

Par exemple, une personne a prénom. Si je mets la variable prénom publique, n'importe qui peut le changer, et ça n'est pas acceptable.
Il faut donc que le prénom soit affecté à la naissance (donc au constructeur) et point bare.

Cet exemple répond à l'exigence
        public Personne(string MonNom, string MonPrenom, DateTime MaDateNaissance)
        {
            Nom = MonNom;
            Prenom = MonPrenom;
            DateNaissance = MaDateNaissance;
        }

public string Prenom { get; private set; }

Alors tu vas me dire, c'est pas vraiment encapsulé, il n'y a pas de variable interne.
C'est exact, mais si tu viens à en avoir besoin, tu peux le faire sans que cela ait une influence sur le reste du programme

Comme ça

private string prenom;

public string Prenom
        {
            get { return prenom; }
            private set { prenom = value; }
        }

ou comme ça

public string Prenom
        {
            get { return prenom; }
        }


A première vue, la première option est verbeuse pour pas grand chose. Cependant, si tu veux utiliser le binding, tu devras implémenter INotifyPropertyChanged. Dans ce cas, cette écriture sera nécessaire

private string prenom;

public string Prenom
        {
            get { return prenom; }
            private set 
            {
                prenom = value;
                if (this.PropertyChanged != null) 
                     this.PropertyChanged("Prenom")
            }
        }


Ensuite, pour la lisibilité, tu peux très bien déclarer les variables qui ne servent qu'à une méthode juste au-dessus de cette méthode, comme dans mon exemple. Et celle qui sont utilisées plus globalement dans la classe, tu peux les mettre tout en haut, au-dessus du constructeur.
Ou si tu préfères, toutes les regrouper au même endroit.


Enfin, en se référant à ta précédente question, je pense que les classe imbriquées sont bien plus illisibles que 50 variables rangées selon une norme qui te convienne.
Quand j'étais petit, la mer Morte n'était que malade.
George Burns

MGD Software · Answer

Placer les variables "pseudo-statiques" juste avant la fonction qui les utilisent, je suis d'accord.

Cependant, j'avais souvent des variables statiques qui portaient le même nom, comme par exemple "bInit", drapeau qui signalait que les initialisations avaient été faites (notamment utile dans les fonctions réentrantes ou appelées en boucle).

En les plaçant en dehors de la fonction, elles ne pourront plus avoir le même nom, puisqu'elles auront toutes la même portée "classe".
Mais puisqu'on ne peut pas faire autrement...

Concernant les classes imbriquées, il s'agit d'une erreur de jeunesse² (!). Je ne le referai plus, c'est promis.

Ce n'était pas possible en VB, et j'avais trouvé cela pratique pour représenter la structure des fichiers XML obtenus par sérialisation. Mais il est vrai qu'au point de vue déclaration des variables, c'est pas le pied : WebAlbum.collection.styles.body machin = new WebAlbum.collection.styles.body() est moins facile à écrire que body machin = new body()
Cela permet cependant d'avoir des classes de nom identique mais pas de structure identique. J'ai besoin de cela pour générer les fichiers XML utilisés par Javascript pour créer les classes CSS des pages web de mon application. Les styles portent les mêmes noms, mais ne sont pas les mêmes selon le type de page web.

Par exemple
WebAlbum.collection.common.styles.body n'a pas la même structure que WebAlbum.album.common.styles.body.

Certes je pourrais les appeler autrement, mais je dois respecter le format actuel pour rester compatible avec les anciennes versions du logiciel développé en VB.

Mais c'est sûr, pour une nouvelle appli, je ne le referai plus.

@+

PS : si tu es curieux, tu peux avoir un aperçu du logiciel VB à l'adresse http://mgd.software.free.fr/downloads/Freewares/WebAlbums/WebAlbums.php
ou sa doc : http://mgd.software.free.fr/downloads/Freewares/WebAlbums/WebAlbums.pdf

(²) Je vais avoir bientôt 72 ans...

Whismeril · Answer

Pour appeler deux classes pareil, il suffit de les déclarer dans 2 namespaces differents.
Pour les utiliser tu fais

namespace1.Body
namespace2.Body
Cela reste plus court que
WebAlbum.collection.common.styles.body


Un truc qui marche avec les namespce à rallonge (pour les classes imbriquées je ne sais pas) est de faire un alias, dans le corps de la classe (pas tout en haut)

using monAlias = System.Windows.Drawing;
Quand j'étais petit, la mer Morte n'était que malade.
George Burns

MGD Software · Answer

OK. Merci.

J'ai une foule d'autres questions qui se préparent, notamment au sujet du FTP.
Mais cela fera l'objet d'un autre topic. Il ne faut pas tout mélanger, pour ceux que cette discussion pourrait intéresser. On s'est déjà pas mal écarté du sujet initial.

@+

Variable "statique"

6 réponses

Votre réponse

Discussions similaires