Discussion :

[ngmsky]

Bonjour,
comme vous l'aurez compris mon roblème est au niveau de la porté des variables.

Je dois écrire une class qui devrait être utilisée par plusieurs projet, par liaison et non par import.
C'est un peu comme include en php.

Cad, je veux que Couple.java situé : /home/compte1/chemin/vers/MesClassPartagees/Couple.java, soit (RE)utilisée par n'importe autres projet java, situé n'importe où sur mon pc.
J'ai essaie, de l'inclure dans plusieurs projets différents, situé dans des dossiers différents, et ça marche très bien, mais à une condition : "sacrifier la sécurité/portée" des méthodes, en les déclarant forcement en public au lieu de protected, comme je le souhaitais (c'est là le problème que je veux résoudre).

(PS : pour l'inclure, dans eclipse, clique droit sur le nom du projet > Build Path > Link source > parcourir et selectionner le dossier .../MesClassPartagees/)

Voici le scénario du problème :

dans Couple.java j'ai ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
package MesClassPartagees ;

public class Couple {
	private int x, y ; 

	protected void setX(int x) { this.x = x ;	}	
	protected int getX() { return x ; }
	
	protected void setY(int y) { this.y = y ;	}	
	protected int getY() { return y ; }	
}

une fois cette class (Couple.java) liée à un projet quelconque situé par exemple dans : /home/compte1/AutreChemin/ ... Appelant1.java
(NB : la class Appelant1.java est donc bien hors du package de Couple.java. )

Pour utiliser la class Couple.java, dans la class Appelant1.java

------------------

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
21
...
import  MesClassPartagees.* ;
// ou import  MesClassPartagees.Couple ;

public class Appelant1 {
	private Couple c1 = new Couple() ;
	
	public Appelant1() { }
	
	protected void test()
	{
		c1.setX(2); c1.setY(4); 
		System.out.println("x de c1 = " + c1.getX() + " -- et y de c1 = " + c1.getY());
	}

	public static void main(String[] args) {		
		Appelant1 ap1 = new Appelant1() ;
		ap1.test(); 		
		}
}

----------------

Mais impossible d'executer car eclipse me signale les erreurs (en rouge) :
erreur : The method setX(int) from the type Couple is not visible
erreur : The method setY(int) from the type Couple is not visible

Il m'a fallut modifier la class Couple.java en rendant les setters et les getters public au lieu de protected.


Voici la nouvelle class Couple.java

Code :

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

1
2
3
4
5
6
7
8
9
10
11
package MesClassPartagees ;

public class Couple {
	private int x, y ; 

	public void setX(int x) { this.x = x ;	}	
	public int getX() { return x ; }
	
	public void setY(int y) { this.y = y ;	}	
	public int getY() { return y ; }	
}

Et maintenant que les setters et getters de Couple.java sont public, il n'y a plus d'erreur dans appelant.java, qui s'exécute très bien, en affichant ce ci :

x de c1 = 2 -- et y de c1 = 4

Inclusion de Couple.java réussite mais au prix du sacrifice de la sécurité, puisque n'importe quelle casse pourra désormais lire ou modifier les variables de des objets Couple.

C'est là l'origine de ma question : c1 est-il sécurisé ? private Cla c1 = new Cla() -- sachant que setter et getter dans Cla sont public


si l'explication n'est pas très claire, je peux toujours reformuler.


Merci d'avance pour vos réactions.

[joel.drigo]

Salut,

Si tu veux pouvoir appeler une méthode d'une classe dans un autre package, il n'y a pas à tortiller, la méthode doit être public. Quand tu parles de sécurisation, je suppose que tu fais référence à ton autre discussion. Et je t'y ai répondu que la portée n'a rien à voir avec la sécurité.

Je dois écrire une class qui devrait être utilisée par plusieurs projet, par liaison et non par import.
C'est un peu comme include en php.

Cela ne veut rien dire. Il n'y a pas d'include en Java (procédé d'importer un fichier dans un autre). Pour utiliser une classe dans une classe d'un autre package, on l'importe, point final (sauf pour les classes du package java.lang, qui sont importées automatiqueemnt). Et ta notion de liaison n'y change rien (c'est juste un outil de l'IDE qui permet d'avoir la classe dans le classpath, sans passer par une bibliothèque, ou la mettre dans les sources du projet). Ceci n'est pas une notion Java.

Pour répondre à ta question dans le titre, le private ne rend pas ta variable c1 sécurisée ou non sécurisée. Elle n'est simplement qu'accessible depuis la classe qui la déclare (et encore on peut le contourner relativement facilement). La façon qu'on écrit une classe ne fait que définir un contrat d'utilisation de cette classe. Aucun contrat ne force de façon incourtournable quoique ce soit. Comme un contrat de travail ou contrat de vente. C'est simplement que tu dis aux utilisateurs de cette classe comment ils doivent l'utiliser (la variable private ne doit pas être manipulée directement) : s'ils font autrement, et que ça foire, c'est leur problème, pas le tien. Si tu changes le nom de la variable 2 ans après et qu'ils ont contourné l'accessibilité pour y accèder et que leur programme ne fonctionne plus, c'est leur problème pas le tien : en déclarant la variable private, tu leur as dit qu'ils ne devaient pas y accèder directement,

Après, on peut écrire le code pour empêcher n'importe qu'elle classe d'invoquer une méthode, mais c'est plutôt compliqué, et la plupart du temps, ça ne sert pas à grand chose. D'autant plus que pour manipuler une instance, il en faut la référence.

[ngmsky]

Bonjour joel.drigo;8921268 et vraiment merci encore pour ton aide, qui m'a permis de considérer ces deux questions comme RÉSOLUES.

Salut,

Si tu veux pouvoir appeler une méthode d'une classe dans un autre package, il n'y a pas à tortiller, la méthode doit être public. Quand tu parles de sécurisation, je suppose que tu fais référence à ton autre discussion. Et je t'y ai répondu que la portée n'a rien à voir avec la sécurité.

Oui, exactement, mais c’était avant que tu me rassure que la portée ne change rien à la "sécurité" de l'application et/ou des données.

Cela ne veut rien dire. Il n'y a pas d'include en Java (procédé d'importer un fichier dans un autre). Pour utiliser une classe dans une classe d'un autre package, on l'importe, point final ... . Et ta notion de liaison n'y change rien (c'est juste un outil de l'IDE qui permet d'avoir la classe dans le classpath, sans passer par une bibliothèque, ou la mettre dans les sources du projet). Ceci n'est pas une notion Java.

En faite, je suis d'accord avec toi que ce n'est pas de l'inclusion d'un fichier (ou code source) d'un un autre, exactement comme le fait php, mais je voulais juste prendre ça en image pour expliquer ce que j'ai découvert, remarqué et que je souhiate exploité (sur l'IDE clipse).
En faite j'ai remarqué une différence entre importation et liaison sur eclipse.

Quand j'importe une ressource A (une class ou un package), les ressources importé sont copiées dans les projets de destination P1, P2, ..., Pn.

Toutes modification de A, ne se repercute pas sur les autres projets contenant cette ressource A.
Ainsi, pour mettre à jour tout les A, je suis obligé, soit de refaire des importations de A, soit de faire des copier/coller manuellement du nouveau A vers tout les projets le contenant.

Non seulement que c'est pénible quand A est copié dans plusieurs projets, mais cela peut engendré des erreurs (oubli de mise à jour cad copier/coller vers un des projet).

Or, en faisant une liaison (par eclipse), A n'est pas physiquement copié vers les P1, ... Pn. Je pense qu'eclipse crée une "sorte de lien symbolique". Ainsi, en modifiant A de n'importe où, c'est un uniquement le A original qui est réellement modifié et tout les projets le contenant auront instantanément la dernière version de A, sans faire quoi que se soit.

A devient une ressource (class, package, ...) partagée.

C'est ce côté ressource partagée que je voulais montrer quand je l'ai comparé à include de php (qui est aussi une sorte de partage d'une ressource).

Pour répondre à ta question dans le titre, le private ne rend pas ta variable c1 sécurisée ou non sécurisée. Elle n'est simplement qu'accessible depuis la classe qui la déclare (et encore on peut le contourner relativement facilement).

Pour la "sécurité", oui, nous sommes bien d'accord. mais pour la "contourner relativement facilement", pour une variable private, c'est vraiment curieux de l'apprendre.
Par curiosité, fais-tu allusion à l'introspection/reflexion ?

La façon qu'on écrit une classe ne fait que définir un contrat d'utilisation de cette classe. Aucun contrat ne force de façon incontournable quoique ce soit. Comme un contrat de travail ou contrat de vente. C'est simplement que tu dis aux utilisateurs de cette classe comment ils doivent l'utiliser (la variable private ne doit pas être manipulée directement) : s'ils font autrement, et que ça foire, c'est leur problème, pas le tien. Si tu changes le nom de la variable 2 ans après et qu'ils ont contourné l'accessibilité pour y accèder et que leur programme ne fonctionne plus, c'est leur problème pas le tien : en déclarant la variable private, tu leur as dit qu'ils ne devaient pas y accèder directement,

Alors là, c'est maintenant très très clair. Je n'avais jamais appris la portée en java sous cette vision.
La portée restrictive (private, protected) ne seraient que :
- des directives, des instructions, (pour garantir le bon fonctionnement d'une class, programme, ...)
- et non des vraies contraintes pures et dures.

Après, on peut écrire le code pour empêcher n'importe qu'elle classe d'invoquer une méthode, mais c'est plutôt compliqué, et la plupart du temps, ça ne sert pas à grand chose. D'autant plus que pour manipuler une instance, il en faut la référence.

Oui, tout à fait d'accord.

Merci encore une fois pour m'avoir aidé à mieux comprendre cette notion de portée en java.

A bientôt

[joel.drigo]

En faite j'ai remarqué une différence entre importation et liaison sur eclipse.

Quand j'importe une ressource A (une class ou un package), les ressources importé sont copiées dans les projets de destination P1, P2, ..., Pn.

Toutes modification de A, ne se repercute pas sur les autres projets contenant cette ressource A.

Ainsi, pour mettre à jour tout les A, je suis obligé, soit de refaire des importations de A, soit de faire des copier/coller manuellement du nouveau A vers tout les projets le contenant.

Non seulement que c'est pénible quand A est copié dans plusieurs projets, mais cela peut engendré des erreurs (oubli de mise à jour cad copier/coller vers un des projet).

Or, en faisant une liaison (par eclipse), A n'est pas physiquement copié vers les P1, ... Pn. Je pense qu'eclipse crée une "sorte de lien symbolique". Aison, en modifiant A de n'importe où, c'est un uniquement le A original qui est réellement modifié et tout les projets le contenant auront instantanement la dernière version de A, sans faire quoi que se soit.

A devient une ressource (class, package, ...) partagée.

C'est ce côté ressource partagée que je voulais montrer quand je l'ai comparé à include de php (qui est aussi une sorte de partage d'une ressource).

Effectivement pour le côté "obligé de recopier les modifications". Seulement, la plupart du temps, on travaille sur des API différentes séparemment, donc ça ne pause pas vraiment de souci. Mais il peut arriver en effet de devoir travailler de concert sur 2 APIs différentes telle que l'une utilise l'autre. Dans ce cas, personnellement, je travaille plutôt avec un dossier de source lié (une sorte de lien symbolique géré par Eclipse. Mais tu peux faire comme tu fais, surtout si tu n'as qu'une seule classe partagée.

Pour la "sécurité", oui, nous sommes bien d'accord. mais pour la "contourner relativement facilement", pour une variable private, c'est vraiment curieux de l'apprendre.
Par curiosité, fais-tu allusion à l'introspection/reflexion ?

Exactement. Mais pas seulement. On peut par exemple contourner protected en jouant sur le package.

Alors là, c'est maintenat très très clair. Je n'avais jamais appris la portée en java sous cette vision.
La portée restrictive (private, protected) ne seraient que :
- des directives, des instructions, (pour garantir le bon fonctionnement d'une class, programme, ...)
- et non des vraies contraintes pures et dures.

Oui. Mais contourner ces directives est coûteux (en temps d'exécution en particulier, et ne serait-ce qu'en clareté de code, sans parler de la maintenabilité et des problèmes de compatibilité ascendante) et non conseillé.