›

Quel différence y a t il entre les variables Private, Protected et Public ?

zenxzenx Membre
13:15 modifié dans API AppKit #1
En fait ma question est plus complète. J'aimerais non seulement connaà®tre les subtilités entre ces différents modes de variable (Private, Protected et Public), mais je souhaiterais également savoir quand privilégier les méthodes d'acces (ou accesseur) plutôt que le symbol de déférencement -> pour acceder à  une variable. En bref, y a t-il des equivalences dans tout cela ou des différences et dans tous les cas quelles en sont leurs natures ?.

D'avance merci !  ;)

Réponses

  • AntilogAntilog Membre
    13:15 modifié #2
    Les variables d'instance:
    Public: accessible par tous les objets(devrait être interdit??)
    Private: accessible par cette classe et les classes héritées de celle-ci (comportement par défaut)
    Protected: accessible seulement par cette classe (ultra-sécuritaire, par exemple si tu publies la classe).

    La règle semble d'utiliser systèmatiquement les accesseurs,  même dans la classe elle-même (sauf pour la méthode qui implémente les accesseurs  :o ).
    Normalement, on ne devrait jamais utiliser la variable sans passer par son accesseur dans un autre objet  :brule: (sauf si l'accesseur n'existe pas...).
  • BruBru Membre
    13:15 modifié #3
    dans 1134042949:

    Private: accessible par cette classe et les classes héritées de celle-ci (comportement par défaut)
    Protected: accessible seulement par cette classe (ultra-sécuritaire, par exemple si tu publies la classe).


    Il y a intervertion entre @private et @protected.

    C'est bien @private qui n'autorise la vue des variables d'instance que dans la classe elle-même, alors que @protected l'autorise aussi pour les sous-classes.

    Par défaut, les variables d'instance sont toujours @protected.

    .
  • AliGatorAliGator Membre, Modérateur
    13:15 modifié #4
    Ah tiens à  ce propos vous n'auriez pas un moyen mnémotechnique pour faire la différence entre @private et @protected ? ??? Je confond toujours les deux, je ne sais jamais lequel laisse l'ouverture aux classes dérivées et lequel restreinte à  la classe seule ? :o
  • BruBru Membre
    13:15 modifié #5
    dans 1134045402:

    Ah tiens à  ce propos vous n'auriez pas un moyen mnémotechnique pour faire la différence entre @private et @protected ? ??? Je confond toujours les deux, je ne sais jamais lequel laisse l'ouverture aux classes dérivées et lequel restreinte à  la classe seule ? :o


    Pour moi, le mot privé me semble plus fort que protégé.

    Tu protèges ta maison, donc ce qui est à  l'extérieur n'a pas de droit d'entrée, mais les autres habitants (les sous-classes) y circulent tout de même.

    Ta chambre est privée : donc seul toi peux y aller, et y faire les choses secrètes que personne ne doit voir...

    .
  • zenxzenx Membre
    13:15 modifié #6
    Merci pour toutes vos réponses !. Donc si je vous suis, je n'utiliste jamais le symbole de déférencement -> pour acceder à  une variable et je lui préfère une méthode d'acces !?.
  • zenxzenx Membre
    13:15 modifié #7
    Lorsque je crée une méthode d'acces à  une variable de ma classe, celle-ci sera accessible à  n'importe quel endroit du programme ?. Et si oui cela ne revient il pas à  déclarer une variable public ?.

    D'autres part, quel est la forme la plus acceptable pour une methode d'acces ?. Est ce que le code qui suit est convenable ? :

    int maVar;

    // méthode d'acces de maVar

    - (int)maVar {
      return maVar;
    }
  • AntilogAntilog Membre
    13:15 modifié #8
    Pardonnes-moi pour l'inversion private/protected  >:)

    Oui, on n'utilise quasiment jamais le déférencement en Objective-C, d'ailleurs j'avais cherché longuement après la syntaxe, à  l'époque...
  • AntilogAntilog Membre
    13:15 modifié #9
    dans 1134047361:

    Lorsque je crée une méthode d'acces à  une variable de ma classe, celle-ci sera accessible à  n'importe quel endroit du programme ?. Et si oui cela ne revient il pas à  déclarer une variable public ?.

    D'autres part, quel est la forme la plus acceptable pour une methode d'acces ?. Est ce que le code qui suit est convenable ? :

    int maVar;

    // méthode d'acces de maVar

    - (int)maVar {
      return maVar;
    }


    Non!
    la variable est encapsulée dans l'objet qui la contient.
    La valeur de cette variable sera accessible à  n'importe quel endroit du programme pour peu qu'il ait accès à  l'objet de cette classe dont tu veux connaà®tre la valeur de sa variable (je ne sais pas si cette phrase est compréhensible...)

    Si tu n'implémentes que maVar, personne ne peux modifier la valeur, sauf l'objet lui-même.

    Pour les variables numériques simples,  ton accesseur me semble très convenable  :adios!:
  • SystemSystem
    13:15 modifié #10
    Pour toutes les variables non mutable en fait.
  • zenxzenx Membre
    13:15 modifié #11
    Et pour une variable de type NSArray par exemple, cela n'est il pas dangereux d'ecrire la méthode d'acces sous cette forme :

    NSArray *monTableau;

    - (NSArray *)monTableau {
      return monTableau;
    }
  • SystemSystem
    13:15 modifié #12
    C'est une classe non mutable donc pas de souci.
  • zenxzenx Membre
    13:15 modifié #13
    Merci pour ces réponses  .

    Quel est alors la forme correct pour une variable de type objet mutable (je sais pas si ça se dit) comme suivant :

    NSMutablearray *monTableau;

    - (NSMutablearray *)monTableau {
      return monTableau
    }

    Dans tous les cas puis je donc écrire ma méthode d'acces ainsi ?

    Pardon d'insister !  ;)
  • SystemSystem
    13:15 modifié #14
    tu peux, mais il y a un risque qu'un objet extérieur le modifie, et ça ce n'est pas toujours recommandé, car pour modifier une variable d'instance, il est recommandé de passer par des méthodes de la dite instance, plutôt que la modifier directement.

    Dans le cas des mutables, l'accesseur doit plutôt être:
    return [[myArray copy] autorelease];
  • zenxzenx Membre
    13:15 modifié #15
    Merci pour cette réponse prompte ! 

    Quand tu ecris : return [[myArray copy] autorelease];

    Cela retourne un nouvel Objet (une copie parfaite de myArray) au destinataire et sa décrémente son retaincount (celui de la copie de l'objet) une fois que le destinataire a mit la main dessus c'est bien cela ?.
  • AntilogAntilog Membre
    13:15 modifié #16
    Exact!
    Si le destinataire veut le garder en dehors de sa méthode, il doit faire un retain.
Connectez-vous ou Inscrivez-vous pour répondre.