Notion d'objet (Protected)

Version imprimable

Salut à tous ! Tout d'abord voici mon code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 
 
public class Ville {
 
    protected String nomVille;
    protected String nomPays;
    protected int nbreHab;
 
    public Ville(String nomVille, int nbreHab, String nomPays) {
        this.nomVille = nomVille;
        this.nbreHab = nbreHab;
        this.nomPays = nomPays;
    }
 
    public String decrisToi() {
        return "\t" + this.nomVille + " est une ville de " + this.nomPays + ", elle comporte : " + this.nbreHab+" habitants";
 
    }
 
    /**
     * @return the nomVille
     */
    public String getNomVille() {
        return nomVille;
    }
 
    /**
     * @param nomVille the nomVille to set
     */
    public void setNomVille(String nomVille) {
        this.nomVille = nomVille;
    }
 
    /**
     * @return the nomPays
     */
    public String getNomPays() {
        return nomPays;
    }
 
    /**
     * @param nomPays the nomPays to set
     */
    public void setNomPays(String nomPays) {
        this.nomPays = nomPays;
    }
 
    /**
     * @return the nbreHab
     */
    public int getNbreHab() {
        return nbreHab;
    }
 
    /**
     * @param nbreHab the nbreHab to set
     */
    public void setNbreHab(int nbreHab) {
        this.nbreHab = nbreHab;
    }
}

Voici la classe ville, où, comme vous pouvez le voir, les propriétés sont "protected". Donc si j'ai bien compris elle ne devrait pas être accéssible de cette manière :

Code:

1
2
Ville maVille = new Ville("Marseille",13000,"France");
maVille.nomPays = "Japon";

Cependant, dans mon code c'est tout à fait possible... Une petite idée ?

31/12/2010, 17h51
Jose.N70
Citation:

Les variables, méthodes ou classes définies comme protégées ne sont accessibles que par les classes filles et classes du même package..

Donc si ta méthode
Code:

1 2 Ville maVille = new Ville("Marseille",13000,"France"); maVille.nomPays = "Japon";
se trouve dans le même package logiquement ça reste accessible. Pour les rendre inaccessible il faut utiliser private

La faq dit :

Les variables, méthodes ou classes définies comme privées ne sont accessibles que par la classe dans laquelle elles sont définies.

Il est fortement conseillé de déclarer comme privés tous les attributs d'une classe, et de créer des méthodes de type get/set pour y accéder.
31/12/2010, 18h01
Adel13

J'ai du mal à comprendre " class du même package " .

Sinon, si je met private, les classes filles ne pourront pas en hérité non ?
31/12/2010, 18h05
Jose.N70

Citation:

Envoyé par Adel13

J'ai du mal à comprendre " class du même package " .

Sinon, si je met private, les classes filles ne pourront pas en hérité non ?

Les classes situées dans le même package veut dire toutes les classes qui sont dans le package genre fr.test.utils ....

Le mieux, est de mettre les attributs en private et y accéder depuis les getter et setter
31/12/2010, 18h10
Adel13

Donc en gros "protected" ne sert pas à grand chose ?
31/12/2010, 18h18
Jose.N70

C'est entre le public et le private ... ça peut servir ( pour ma part je m'en sers pas mais je ne suis pas un grand développeur )
01/01/2011, 02h17
thelvin

Citation:

Envoyé par Adel13

Donc en gros "protected" ne sert pas à grand chose ?

Pas quand on ne comprend pas ce qu'est un package, en tout cas ;).

Effectivement, cette notion un peu trop volage de "protected" impose d'éclater ses projets en plusieurs packages, et de ne garder dans un même package que des classes qui sont suffisamment unies pour que l'accès à protected ne soit pas un problème.

Disons que quand on apprend, il faut se dire que c'est "presque" accès aux sous-classes uniquement. Et ne pas trop s'étonner quand les classes "à côté" y ont accès sans être des sous-classes. On a dit presque.

Prenons un exemple dans une classe tu codes une méthode public que tu vas appeler "Message", si tu instancie cette classe, tu peux voir ta méthode Message. Dans le cadre ou tu crée une méthode Protected que tu vas appeler "MessagePrive" Tu ne la verra pas. Les méthodes protected sont la pour être utilisé dans des notions d'héritage.

Imaginons que tu créer un seconde classe qui va hérité des méthodes de la première. A l'intérieur de ta classe dans une nouvelle méthode si tu fais un "base." tu vas voir apparaitre ta méthode Protected avec un petit cadenas.

Essaie de mettre dans ca dans une application console.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ConsoleApplication1 { public class MyTest { public void Message() { } protected void MessagePrivee() { } } public class MyTest2 : MyTest { public void TestMessagePrivee() { base.MessagePrivee(); } } class Program { static void Main(string[] args) { MyTest ThisTest = new MyTest(); ThisTest.Message(); MyTest2 ThisTEst2 = new MyTest2(); ThisTEst2.Message(); ThisTEst2.TestMessagePrivee(); } } }
P.S. Si tu ne connais pas les notions d'heritage en C# il faut vraiment t'y mettre c'est l'une des choses importante dans le domaine.

Citation:

Envoyé par Adel13

Donc en gros "protected" ne sert pas à grand chose ?

si, bien sûr que si.
Pour simplifier : l'encapsulation conduit parfois des sous-classes à disposer de choses auxquelles elle n'ont pas accès (on a effectivement une variable membre mais elle est private dans la super-classe).
Il est bon, pour conserver l'encapsulation, que ces variables membres restent private .... Mais supposons que ces variables ne soient pas dotées d'un accesseur/mutateur (get/set) parce que précisément elles sont liées à un mécanisme interne.
On peut alors mettre en place un code qui dise ceci: " ce code n'est pas un service -comme une méthode classique- mais c'est un mécanisme interne lié à l'objet" ce code est alors protected.
C'est un mécanisme interne: il reste éventuellement accessible par les codes du même package.
C'est un mécanisme lié à l'objet courant: donc il n'est accessible dans les sous-classes que par this.code() (quand on a une méthode d'instance protected).

(c'est une explication très simplifiée: protected est très utile mais c'est pas trivial à comprendre!)
Code:

1 2 3 4 5 6 7 8 9 10 11 package fr.grosse_banque.gestion ; public class Compte { // connaitra de nombreuses sous-classes private Stockage<Operation> historique; protected void addOperation(Operation op) { historique.add(op) ; } }
maintenant les sous-classes CompteLivret , etc... situées dans d'autres packages pourront enregistrer des opérations sans connaître le type réel Stockage.
Par ailleur cette méthode addOperation est appelée depuis les méthodes depot et retrait et ne doit pas être appelée "de l'extérieur" (c'est ce que j'appelle un "mécanisme interne").
Note bien ceci par ailleurs:
Code:

1 2 3 4 5 6 7 8 9 package com.filiale.bizness ; class CompteEpargne extends Compte { void copieOperation(Operation op, Compte autreCompte) { autreCompte.addOperation(op) ; } }
ce code ne se compile pas!
normal: on essaie d'accéder à un mécanisme interne d'une autre instance d'un type qu'on ne controle pas!