IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JavaScript Discussion :

Variable static et prototype


Sujet :

JavaScript

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Homme Profil pro
    Inscrit en
    Mars 2013
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2013
    Messages : 30
    Par défaut Variable static et prototype
    Bonjour,
    Si je veux déclarer une variable de type static, je peux le faire dans le corps de définition de la fonction (comme pour x).
    Je peux aussi déclarer une variable dans le prototype (comme pour y).
    Quel est l'intérêt d'une méthode par rapport à l'autre ?
    (à part que dans le second cas il me faut un objet pour y accéder, donc un peu moins pratique peut-être...)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    function maClasse{
     arguments.callee.x=0;
    }
    maClasse.prototype={
      y:0
    };

  2. #2
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Par défaut
    Non, ce n'est pas tout à fait la même chose. arguments.callee peut ici être remplacé par maClasse, donc x est une propriété de la fonction maClasse. Tandis que y est une propriété du prototype de maClasse. La différence majeure est que si l'on construit une instance avec le constructeur maClasse: var monInstance = new maClasse(); ; l'instance héritera des propriétés du prototype de maClasse mais pas des propriétés de maClasse directement. Donc monInstance.y sera défini mais pas monInstance.x. Aussi, si tu modifies la propriété y d'une instance, celle du prototype ne sera pas modifiée ; donc y n'est pas une propriété statique.

    Si on prend la définition Java d'une variable statique, à savoir partagée par toutes les instances d'une même classe, alors en JavaScript il suffit d'attacher cette propriété à une portée parente. Il peut s'agir de la fonction constructeur comme tu l'as fait avec x, mais on peut aussi prendre n'importe quelle variable de portée parente, locale ou globale :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    var compteur = 0; //variable locale statique
    function maClasse{
     arguments.callee.x=0; compteur++;
    }
    maClasse.prototype={
      y:0
    };
    };
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    window.compteurMaClasse = 0; //variable globale statique
    function maClasse{
     arguments.callee.x=0; 
     window.compteurMaClasse++;
    }
    maClasse.prototype={
      y:0
    };
    };

  3. #3
    Membre averti
    Homme Profil pro
    Inscrit en
    Mars 2013
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2013
    Messages : 30
    Par défaut une autre question...
    Tu as raison. Il y a donc copie du prototype pour chaque instanciation. Je voyais plutôt un hash "partagé"...
    Donc il est préférable d'éviter d'y inclure autre chose que des fonctions.
    Autant pour moi !
    La question que je me pose en conséquence, c'est est-ce-que si j'ai beaucoup d'instances, il n'est pas préférable de stocker les méthodes de la classe ailleurs que dans le prototype et d'appeler
    uneMethode.call(this,...);
    au lieu de
    this.uneMethode(...);
    Au niveau de la mémoire, c'est sans doute mieux...

  4. #4
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Par défaut
    En fait, lorsqu'on souhaite récupérer une propriété d'un objet, si celle-ci n'est pas trouvée dans l'objet, on regarde dans le prototype de l'objet et le prototype de ce prototype etc... ça s'appelle remonter la chaîne prototypale. Donc c'est bien un partage, tant que la propriété n'a pas été modifiée spécifiquement pour l'instance. Vérification:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    function maClasse(){ arguments.callee.x=0;}maClasse.prototype={ y:0};
     
    var monInstance2 = new maClasse();
    monInstance.y; // == 0, y récupéré depuis le prototype
    Object.keys(monInstance); // == [] array vide, monInstance n'a pas de propriétés non héritées
    monInstance.y+=1; //1, on modifie une propriété du prototype qui du coup devient une propriété propre à monInstance
    Object.keys(monInstance); // == ["y"]
    Ceci dit rien ne t'empêche de mettre autre chose que des fonctions dans le prototype, c'est comme ça qu'on fait de l'héritage en JavaScript. En Java on distingue les classes et les interfaces, mais en JavaScript tout est objet (et je trouve ça personnellement bien plus simple bien que ça déconcerte beaucoup de devs venant d'autres langages)

    Pour l'histoire de la mémoire, non ça ne change quasiment rien. Mieux vaut mettre les propriétés dans le prototype: ça rejoint davantage le principe de programmation objet et ça permet aux méthodes d'accompagner l'objet ; on est pas obligés de s'assurer qu'elles sont toujours à portée et de les appeler avec .call

  5. #5
    Membre averti
    Homme Profil pro
    Inscrit en
    Mars 2013
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2013
    Messages : 30
    Par défaut merci pour tes explications très claires
    Ma réponse est un peu tardive, fêtes obligent...

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [C++] Pb avec les variable static dans les classe
    Par quantik-revolution dans le forum C++
    Réponses: 3
    Dernier message: 03/03/2006, 18h40
  2. [C#] Variable static
    Par fremsoi dans le forum Windows Forms
    Réponses: 12
    Dernier message: 25/01/2006, 21h07
  3. [VB6]Initialiser une variable Static dans un évenement
    Par loverdose dans le forum VB 6 et antérieur
    Réponses: 16
    Dernier message: 20/01/2005, 14h57
  4. [héritage] héritage d'une variable static
    Par yaya44 dans le forum Langage
    Réponses: 14
    Dernier message: 29/09/2004, 13h36
  5. Variable static avec thread
    Par oxor3 dans le forum Threads & Processus
    Réponses: 7
    Dernier message: 27/08/2004, 11h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo