Discussion :

[pflany]

Bonjour,
Je ne suis pas un développeur JAVA, mais j'aimerais comprendre le principe de structure du langage. je m'exprime sans doute mal, quand je dis "structure", je veux parler de cette profusion de répertoire.
Quel est le sens d'avoir 4-5 répertoire et sous-répertoire avant d'arriver à ses fichiers de développement ?
J'ai lu que cela se faisait pour éviter les conflits de nommage, est ce que cela veux dire que cela protège les variables ? (ça me semble bizarre...)
ou alors ce sont des conflit sur le nommage des objets et fonctions ?

Bref je suis curieux, je suis actuellement sur un développement Web (php, html, ...) et je me demande si cette technique à une autre utilité qui pourrait s'étendre à d'autre langage ?

ou bien je suis total irrationnel ... ?

Merci beaucoup de vos réponses.
Ce message n'est que de la curiosité en bloc.

[Baptiste Wicht]

Bonjour,
Je ne suis pas un développeur JAVA, mais j'aimerais comprendre le principe de structure du langage. je m'exprime sans doute mal, quand je dis "structure", je veux parler de cette profusion de répertoire.
Quel est le sens d'avoir 4-5 répertoire et sous-répertoire avant d'arriver à ses fichiers de développement ?
J'ai lu que cela se faisait pour éviter les conflits de nommage, est ce que cela veux dire que cela protège les variables ? (ça me semble bizarre...)
ou alors ce sont des conflit sur le nommage des objets et fonctions ?

Bref je suis curieux, je suis actuellement sur un développement Web (php, html, ...) et je me demande si cette technique à une autre utilité qui pourrait s'étendre à d'autre langage ?

ou bien je suis total irrationnel ... ?

Merci beaucoup de vos réponses.
Ce message n'est que de la curiosité en bloc.

Je ne sais pas trop pourquoi c'est fait, mais je pense que ca doit être, comme tu l'as dit, pour éviter les conflits de nommage. En effet, on a plusieurs classes de même nom mais dans des packages différents. Ca permet aussi une meilleure organisation des classes.

[yann2]

Salut
Disons aussi que la norme veut qu'un nom de package soit du type com.nomdomaine.(etc) ou fr.nomdomaine.(etc) etc.

Chaque fichier classe doit être situé dans une arborescence correspondant à son package. Il est donc plus facile de faire pareil avec les fichiers sources.

Mais bon rien ne t'empêche d'utiliser le package par défaut et tout foutre dans le même répertoire comme un gros porcasse.

[Robert Jean]

Salut
Disons aussi que la norme veut qu'un nom de package soit du type com.nomdomaine.(etc) ou fr.nomdomaine.(etc) etc.

Chaque fichier classe doit être situé dans une arborescence correspondant à son package. Il est donc plus facile de faire pareil avec les fichiers sources.

Mais bon rien ne t'empêche d'utiliser le package par défaut et tout foutre dans le même répertoire comme un gros porcasse.

Cela set à quoi de devenir un temps soit peu vulgaire.
Pourquoi ne pas expliquer une méthode qui convienne à tous ou presque sans pour autant employer des mots de type "porcasse".
Je pense que tu dos te sentir plus grand plus fort meilleur que les autres avec de tel propos.

[@ldehan]

cela a aussi un impact sur la visibilité.

des attributs protected sont visibles dans les classes d'un même package (enfin il me semble , j'ai des doutes d'un coup....)

Mais l'interet initial est effectivement d'eviter les conflits de nomage des classes.

Un tres bon exemple est java.util.Date et java.sql.Date.

Quant a sa portablité a d'autre langage, je ne sais pas trop. Il me semble que quasiment tous les langages objets ont une notion de package ou d'espace de nommage en général.

La représentation de l'espace de nommage physiquement dans les répertoires disques est à mon avis une bonne chose mais c'est peut-etre parce que je suis habitué a travailler comme ca...

[wizaord]

cela a aussi un impact sur la visibilité.

des attributs protected sont visibles dans les classes d'un même package (enfin il me semble , j'ai des doutes d'un coup....)

Mais l'interet initial est effectivement d'eviter les conflits de nomage des classes.

Un tres bon exemple est java.util.Date et java.sql.Date.

Quant a sa portablité a d'autre langage, je ne sais pas trop. Il me semble que quasiment tous les langages objets ont une notion de package ou d'espace de nommage en général.

La représentation de l'espace de nommage physiquement dans les répertoires disques est à mon avis une bonne chose mais c'est peut-etre parce que je suis habitué a travailler comme ca...

Juste sur le point de la visibilité ; les classes d'un package ne peuvent être vue qu'à l'intérieur de ce package si celle ci ne possède pas de préfixe du style (public, private, ....).

[@ldehan]

Juste sur le point de la visibilité ; les classes d'un package ne peuvent être vue qu'à l'intérieur de ce package si celle ci ne possède pas de préfixe du style (public, private, ....).

Apres test, je corrige.

Deux classes d'un meme package ont acces aux membres public (mot-clé 'public'), protected (mot-clé 'protected') et friendly (pas de mot clé)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
package test;
 
public class A1 {
 
	public static void main (String[] args){
		A2 a2 = new A2();
		System.out.println(a2.attributFriendly);
		System.out.println(a2.attributProtected);
		System.out.println(a2.attributPublic);
	}
}

Code :

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

1
2
3
4
5
6
7
8
9
package test;
 
public class A2 {
 
	private String attributPrivate = "private";
	protected String attributProtected = "protected";
	public String attributPublic = "public";
	String attributFriendly = "friendly";
}

pour résumé,
private : n'est visible que dans la classe elle-même
friendly : n'est visible qu'a l'interieur du package
protected : n'est visible que dans le package et les sous classes
public : est visible par toutes les classes

[®om]

Code :

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

1
2
3
4
5
              public  protected   (default)   private
Même classe     X        X           X          X
Même package    X        X           X
Sous classe     X        X
Autre package   X

[professeur shadoko]

pour résumé,
private : n'est visible que dans la classe elle-même
friendly : n'est visible qu'a l'interieur du package
protected : n'est visible que dans le package et les sous classes
public : est visible par toutes les classes

faux pour protected! c'est plus subtil que ça.
(pour un membre non static) protected permet d'accéder à un membre de l'instance courante et c'est tout! (d'autres subtilités pour les autres cas).
en d'autres termes:

Code :

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

1
2
3
4
5
 
class Y extends autrepackage.X {
     public void modifie (autrepackage.X autreinstance) {
        this.chamProtected  = // OK
          autreInstance.champProtected ; //fume!