Variable "statique" [Résolu]

MGD Software 52 Messages postés vendredi 1 septembre 2006Date d'inscription 3 décembre 2017 Dernière intervention - 30 nov. 2017 à 12:03 - Dernière réponse : Whismeril 10529 Messages postés mardi 11 mars 2003Date d'inscriptionContributeurStatut 13 décembre 2017 Dernière intervention
- 2 déc. 2017 à 19:08
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 ?
Afficher la suite 

7 réponses

Répondre au sujet
Whismeril 10529 Messages postés mardi 11 mars 2003Date d'inscriptionContributeurStatut 13 décembre 2017 Dernière intervention - 30 nov. 2017 à 17:27
0
Utile
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.
Commenter la réponse de Whismeril
MGD Software 52 Messages postés vendredi 1 septembre 2006Date d'inscription 3 décembre 2017 Dernière intervention - 1 déc. 2017 à 16:24
0
Utile
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.

@+
Commenter la réponse de MGD Software
Whismeril 10529 Messages postés mardi 11 mars 2003Date d'inscriptionContributeurStatut 13 décembre 2017 Dernière intervention - Modifié par Whismeril le 1/12/2017 à 18:14
0
Utile
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
Commenter la réponse de Whismeril
MGD Software 52 Messages postés vendredi 1 septembre 2006Date d'inscription 3 décembre 2017 Dernière intervention - 2 déc. 2017 à 17:00
0
Utile
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...
Commenter la réponse de MGD Software
Whismeril 10529 Messages postés mardi 11 mars 2003Date d'inscriptionContributeurStatut 13 décembre 2017 Dernière intervention - Modifié par Whismeril le 2/12/2017 à 17:16
0
Utile
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
Commenter la réponse de Whismeril
MGD Software 52 Messages postés vendredi 1 septembre 2006Date d'inscription 3 décembre 2017 Dernière intervention - 2 déc. 2017 à 18:31
0
Utile
1
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.

@+
Whismeril 10529 Messages postés mardi 11 mars 2003Date d'inscriptionContributeurStatut 13 décembre 2017 Dernière intervention - 2 déc. 2017 à 19:08
En ce qui concerne le FTP, je ne te serai pas d'une grande aide.
Commenter la réponse de MGD Software

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.