Discussion :

[Laudec]

Bonjour,

je suis actuellement un tuto sur les classes et les héritages.

On y explique que pour protéger une variable d'une erreur de programmation, celle-ci est déclarée private.
Pour qu'une classe héritée (je ne l'ai pas encore créée) puisse néanmoins avoir accès à la variable sans, pour autant, lever la protection au niveau des utilisateurs, il suffit donc de remplacer private par le mot clé protected.

voici donc mon programme principal :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
package projet3;
 
public class Principal {
 
	public static void main(String[] args) 
	{
		Ville v0=new Ville("Paris",100,"France");
		System.out.println(v0.cap);
		v0.cap="Modif";
		System.out.println(v0.cap);
	}
}

et voici la classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package projet3;
 
public class Ville {
	protected String cap, pays;
	protected int hab;
 
	public Ville()
	{
		cap="Default Capitale";
		hab=0;
		pays="Default Pays";
	}
	public Ville(String aa, int bb, String cc)
	{
		cap=aa;
		hab=bb;
		pays=cc;
	}
 
}

Si j'ai bien compris, avec protected, je ne suis donc pas en mesure de modifier les valeurs de v0 à partir de mon programme Principal.
Pourtant, je n'ai aucun mal à changer la valeur de la variable cap, sans faire appel à un mutateur et voici le résultat lorsque je lance programme.



Est ce moi qui n'ai pas compris le principe d'utilisation de protected ?

merci d'avance pour vos explications.

[thelvin]

Hello,

protected autorise aussi l'accès aux classes qui sont dans le même package, or tes deux classes sont dans le package projet3.

Concrètement il y a quatre niveaux de permission d'accès :

- private : classe en cours uniquement
- par défaut, aucun mot-clé, (en général appelé package-private) : uniquement les classes du même package.
- protected : les classes du même package plus les classes filles et descendantes.
- public : tout le monde.

On notera que quand les permissions s'étendent, elles incluent aussi les permissions au-dessus : package-private autorise bien sûr la classe en cours, protected autorise le package en cours, et public autorise évidemment les sous-classes en plus de tout le monde aussi.

Conclusion :

Oui, d'habitude on protège les variables par private. Mais quand on veut que les sous-classes puissent y accéder, il faut étendre la permission à protected. Ce qui l'étend aussi aux autres classes rangées au même endroit.
Ce qui veut dire que ces autres classes ont un peu responsabilité à savoir ce qu'elles font et à ne pas y toucher si elles n'en ont pas besoin. Si elles n'en étaient pas capables, elles ne seraient pas dans le même package, elles seraient rangées ailleurs.

[Laudec]

Merci pour le complément d'info... qui valide le résultat obtenu lors du lancement du programme.

Ce que semble suggérer le cours est donc erroné.

[thelvin]

Ce que semble suggérer le cours est donc erroné.

Pas particulièrement, c'est juste qu'en situation réelle deux classes sont rarement dans le même package.

[Laudec]

merci pour cette autre précision... je pense que ce sont des situations, pour l'instant, un peu prématurées, en ce qui concerne.

cordialement.

[professeur shadoko]

remarque (faite déjà à plusieurs occasions dans ce forum)
en fait le modificateur de portée protected est un peu plus compliqué que ça.
En gros ça veut dire: cet élément est un mécanisme interne qui peut être utilisé en propre par une instance d'une sous-classe mais c'est pas un "service" (rendu à l'extérieur).
kexa veut dire? ben que dans une sous-classe tu ne peux accéder ainsi qu'aux éléments qui t'appartiennent en propre (par this) tu ne peux pas avoir accès à ceux d'une autre instance de la super-classe (on d'une de ses dérivées).
C'est malheureusement pas expliqué dans beaucoup de bouquins (ou de cours)