IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement Mobile en Java Discussion :

c1 est-il sécurisé ? private Cla c1 = new Cla() -- sachant que setter et getter dans Cla sont public


Sujet :

Développement Mobile en Java

  1. #1
    Membre à l'essai Avatar de ngmsky
    Homme Profil pro
    Inscrit en
    août 2011
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : août 2011
    Messages : 39
    Points : 20
    Points
    20
    Par défaut c1 est-il sécurisé ? private Cla c1 = new Cla() -- sachant que setter et getter dans Cla sont public
    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.

  2. #2
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2009
    Messages : 12 430
    Points : 29 095
    Points
    29 095
    Billets dans le blog
    2
    Par défaut
    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é.

    Citation Envoyé par ngmsky Voir le message
    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.
    L'expression "ça marche pas" ne veut rien dire. Indiquez l'erreur, et/ou les comportements attendus et obtenus, et donnez un Exemple Complet Minimal qui permet de reproduire le problème.
    La plupart des réponses à vos questions sont déjà dans les FAQs ou les Tutoriels, ou peut-être dans une autre discussion : utilisez la recherche interne.
    Des questions sur Java : consultez le Forum Java. Des questions sur l'EDI Eclipse ou la plateforme Eclipse RCP : consultez le Forum Eclipse.
    Une question correctement posée et rédigée et vous aurez plus de chances de réponses adaptées et rapides.
    N'oubliez pas de mettre vos extraits de code entre balises CODE (Voir Mode d'emploi de l'éditeur de messages).
    Nouveau sur le forum ? Consultez Les Règles du Club.

  3. #3
    Membre à l'essai Avatar de ngmsky
    Homme Profil pro
    Inscrit en
    août 2011
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : août 2011
    Messages : 39
    Points : 20
    Points
    20
    Par défaut RESOLU
    Bonjour joel.drigo;8921268 et vraiment merci encore pour ton aide, qui m'a permis de considérer ces deux questions comme RÉSOLUES.

    Citation Envoyé par joel.drigo Voir le message
    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.


    Citation Envoyé par joel.drigo Voir le message
    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).


    Citation Envoyé par joel.drigo Voir le message
    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 ?


    Citation Envoyé par joel.drigo Voir le message
    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.


    Citation Envoyé par joel.drigo Voir le message
    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

  4. #4
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2009
    Messages : 12 430
    Points : 29 095
    Points
    29 095
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par ngmsky Voir le message
    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.

    Citation Envoyé par ngmsky Voir le message
    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.


    Citation Envoyé par ngmsky Voir le message
    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é.
    L'expression "ça marche pas" ne veut rien dire. Indiquez l'erreur, et/ou les comportements attendus et obtenus, et donnez un Exemple Complet Minimal qui permet de reproduire le problème.
    La plupart des réponses à vos questions sont déjà dans les FAQs ou les Tutoriels, ou peut-être dans une autre discussion : utilisez la recherche interne.
    Des questions sur Java : consultez le Forum Java. Des questions sur l'EDI Eclipse ou la plateforme Eclipse RCP : consultez le Forum Eclipse.
    Une question correctement posée et rédigée et vous aurez plus de chances de réponses adaptées et rapides.
    N'oubliez pas de mettre vos extraits de code entre balises CODE (Voir Mode d'emploi de l'éditeur de messages).
    Nouveau sur le forum ? Consultez Les Règles du Club.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 3
    Dernier message: 21/01/2017, 09h26
  2. Quelle est la valeur du pointeur si new échoue ?
    Par Stobbyo dans le forum Débuter
    Réponses: 2
    Dernier message: 25/06/2011, 00h30
  3. Réponses: 8
    Dernier message: 26/02/2010, 01h23
  4. psqlODBC est-il sécurisé?
    Par Hannibal dans le forum PostgreSQL
    Réponses: 2
    Dernier message: 10/06/2003, 12h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo