Comment déconseiller ou interdire aux utilisateurs d'appeller une méthode ?

**quentigus** · 16/05/2011, 19h42

Bonjour,

Je code en java depuis 3 ans mais aujourd'hui, je rencontre un problème que je n'ai jamais rencontré auparavant.

Voilà je fais un programme utilisant les design pattern et en fait, j'ai une méthode qui est appelée par un autre objet du programme et j'aimerais bien savoir comment "bloquer" ou dire aux personnes qui reprennent mon code de ne pas utiliser cette méthode.

Ce n'ai pas bien grave mais c'est toujours bon de savoir comment faire.

Je pensais la déprécier dans la javadoc mais je ne pense pas que ce soit le meilleur moyen.

Merci d'avance

Cordialement,
Quentigus

**anisj1m** · 16/05/2011, 19h56

Envoyé par quentigus

Voilà je fais un programme utilisant les design pattern

Comment va servir cela pour décrire votre question

ok juste je rigole,

mais bien sure tu utilises :

Code :

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

1
2
@Deprecated
public type name_method(params){}

**quentigus** · 16/05/2011, 21h14

Envoyé par anisj1m

Comment va servir cela pour décrire votre question

C'est juste que c'est à cause d'un DP que je rencontre ce problème.

Merci

**verbose** · 16/05/2011, 22h23

L'annotation @Deprecated doit être strictement réservées aux méthodes obsolètes, et non aux méthodes dont on voudrait restreindre l'utilisation.

Pour limiter l'utilisation d'une méthode, il faut jouer sur sa visibilité :

private : La méthode est visible uniquement dans la classe et les classes internes
default (sans modificateur) : La méthode est visible dans le package
protected : La méthode est visible dans les sous-classes
public : La méthode est visible dans tous les packages et toutes les classes

Chaque niveau de visibilité hérite de la visibilité des niveaux inférieurs.

Toutefois, il est préférable d'avoir des niveaux de visibilité permissifs pour rendre plus souple l'utilisation de son api. On peut ensuite simplement ajouter dans la javadoc que telle méthode est destinée à un usage interne ou qu'il est préférable d'utiliser un adapter ou un factory, par exemple, dont on fournie le lien avec l'annotation javadoc @see.

**Ivelios** · 17/05/2011, 17h04

+1 verbose.

Utiliser le design pattern Factory.
Créer une interface de la classe concernée sans inclure la dîtes méthode.

Puis dans la factory :

Code :

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

1
2
3
4
public static InterfaceDeMonObjet createObjet(param){
InterfaceDeMonObjet ref = new MonObjet(param);
return ref;
}

Quand tu utilises une factory, normalement, tu n'as plus jamais besoin de faire de new sur tes Objets, tu fais toujours des factory.createMonObjet(param);

Nb : Comme dirait mon prof : " Toute classe doit posséder une interface "

**professeur shadoko** · 18/05/2011, 17h36

protected est parfois utilisé pour ça.
que veut dire "protected" : voici une méthode qui est un mécanisme interne.
elle est à la disposition de la classe courante et des classes du même package.
Certes elle est également accessibles aux sous-classes mais en ce qui concerne l'instance courante (this.methode()).
donc les autres codes (en dehors de ton package) vont se faire jeter s'ils l'utilisent (en dehors d'un héritage)...
plus simple encore: une méthode sans rien: elle ne sera accessible qu'aux classes du même package.

**Logan Mauzaize** · 19/05/2011, 09h49

La question n'étant pas tranchée et précise, ma réponse ne le sera pas plus :

Si tu veux déconseiller l'utilisation d'une méthode car elle n'est pas performante, être remplacé, envisager un autre algorithme pour son intégration dans l'algorithme appelant, etc. C'est @deprected qu'il faut utiliser.

Si tu veux déconseiller l'utilisation d'une méthode car c'est pour un algorithme spécifique, un usage interne, etc. Alors tu ne veux pas le déconseiller mais l'interdire.

Si tu veux interdire l'utilisation d'une méthode, il existe deux moyens : les niveaux de visibilité et la "sécurité".
Pour le premier je ne pense pas qu'après 3 ans de Java tu es besoin d'une explication.
Pour le second j'adopte en général l'approche simple suivante :

Ajouter un attribut "securityKey" de type quelconque T (Object fera très bien l'affaire)
Ajouter au(x) constructeur(s) un paramètre de type T pour initialiser l'objet en question.
Ajouter aux méthodes "sécurisés" un paramètre "key" de type T.
Ajouter un assert aux début des méthodes pour assurer que "key" et "securityKey" sont soit les mêmes objets, soit égaux.

Il te restera à partager convenablement l'instance (ou les valeurs) de "securityKey" entre l'initialisation de ton objet et les méthodes appelantes.

Pour aller plus loin ou pour utiliser des mécanismes plus complexe (et éventuellement se passer de rajouter un paramètre, notamment si tu implémentes une interface que tu ne peux pas modifier) tu peux utiliser un Security Manager, ou encore des Thread-locale variables.

**quentigus** · 19/05/2011, 13h05

Cool ! merci à vous tous je prends note de tout. Pour l'instant j'ai passé ma méthode dans la visibilité par défaut et en jouant sur les packages.

@Ivelios : ton idée de factory peut être pas mal mais recréer mon objet à chaque fois n'est pas super pratique du fait que je modifie souvent ses attributs et va prendre de la mémoire pour pas grand chose (même si le garbage collector fait son boulot enfin c'est ce que je pense, je me trompe peut-être).

Envoyé par Ivelios

Code :

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

1
2
3
4
public static InterfaceDeMonObjet createObjet(param){
InterfaceDeMonObjet ref = new MonObjet(param);
return ref;
}

@Nemec : je testerais bien ta méthode 2 mais je ne vois pas trop comment faire. Est-ce tu aurais un bout de code ou autre pour avoir un exemple ?

Envoyé par Nemek

Pour le second j'adopte en général l'approche simple suivante :

Ajouter un attribut "securityKey" de type quelconque T (Object fera très bien l'affaire)
Ajouter au(x) constructeur(s) un paramètre de type T pour initialiser l'objet en question.
Ajouter aux méthodes "sécurisés" un paramètre "key" de type T.
Ajouter un assert aux début des méthodes pour assurer que "key" et "securityKey" sont soit les mêmes objets, soit égaux.

Il te restera à partager convenablement l'instance (ou les valeurs) de "securityKey" entre l'initialisation de ton objet et les méthodes appelantes.

**tchize_** · 19/05/2011, 13h39

n'oubliez pas que les limitation que vous imposez à vos objets ne devraient pas être excessives. Je me souviens d'une application où on avait besoin de manipuler un object X qui avait été créé de telle manière qu'il était impossible d'en hériter (classe final) et les propriétés dont on avait besoin étaient toutes privées. Résultat: après une semaine de tergiversations sur la manière d'obtenir le résultat voulu, une tartine d'appel via reflection.

**Logan Mauzaize** · 19/05/2011, 14h25

Envoyé par quentigus

@Ivelios : ton idée de factory peut être pas mal mais recréer mon objet à chaque fois n'est pas super pratique du fait que je modifie souvent ses attributs et va prendre de la mémoire pour pas grand chose (même si le garbage collector fait son boulot enfin c'est ce que je pense, je me trompe peut-être).

Le GC fait son boulot comme il veut, quand il veut et quand il peut. Pour résumer si t'as pas besoin de mémoire il se tourne les pouces.
Ceci dit pour les objets temporaires il fait assez bien son travail.

Envoyé par quentigus

@Nemec : je testerais bien ta méthode 2 mais je ne vois pas trop comment faire. Est-ce tu aurais un bout de code ou autre pour avoir un exemple ?

Assez difficile d'être plus explicite

Tout est marqué.
Qu'est-ce que tu n'arrives pas à faire ?

**tchize_** · 19/05/2011, 14h30

le problème des assert Nemek, c'est que beaucoup de gens font tourner leur JVM avec les assertions désactivée, ca risque de ne pas se remarquer que ce n'est pas utilisable

**Logan Mauzaize** · 19/05/2011, 14h36

C'est pas activé par défaut sur la 1.6 ? En tout cas chez moi j'ai ajouté aucune option pour les activer.
Pour les version inférieurs je n'ai pas testé.

On peut facilement remplacer un assert par un bon vieux "if". C'est pour faire plus court

**tchize_** · 19/05/2011, 15h08

activé par défaut mais souvent désactivé explicitement. Ca dépend des écoles de pensées :p

**professeur shadoko** · 19/05/2011, 18h05

Envoyé par Nemek

C'est pas activé par défaut sur la 1.6 ?

ah bon? D'ou vient cette information? j'étais convaincu qu'au runtime c'était désactivé par défaut .... t'es sûr que c'est pas uniquement dans le cadre de codes de compile time (pour des Processeurs d'annotations par exemple?).
merci pour tout lien qui confirmerait/infirmerait ce point.

**tchize_** · 19/05/2011, 18h29

les assertions sont désactivées par défaut:
http://java.sun.com/developer/techni...LP/assertions/

Par contre eclipse (et peut etre netbeans) les active pour tout code lancé depuis l'IDE.

**professeur shadoko** · 20/05/2011, 09h01

Envoyé par tchize_

Par contre eclipse (et peut etre netbeans) les active pour tout code lancé depuis l'IDE.

testé sur éclipse: mon eclipse (helios) ne le fait pas par défaut, netbeans non plus (je dois avoir un sort jeté sur mon ordi) seule l'option -ea dans le projet le déclenche....

**quentigus** · 20/05/2011, 17h58

Envoyé par Nemek

Assez difficile d'être plus explicite

Tout est marqué.
Qu'est-ce que tu n'arrives pas à faire ?

En fait, j'ai compris en essayant de le coder hier et sa marche bien. J'aurais du essayer avant de demander.

Et puis l'assert, un petit tour sur la javadoc et sur google et hop c'est fonctionnel

**tchize_** · 20/05/2011, 18h25

Envoyé par professeur shadoko

testé sur éclipse: mon eclipse (helios) ne le fait pas par défaut, netbeans non plus (je dois avoir un sort jeté sur mon ordi) seule l'option -ea dans le projet le déclenche....

Et t'es contagieux. Je sais pas pourquoi, la dernière fois que j'ai lancé des unit tests les assert dans le code marchaient et plus maintenant, mais t'as raison, c'est toujours à la demande

Bon week-end.

Comment déconseiller ou interdire aux utilisateurs d'appeller une méthode ?

avec Java

Discussions similaires

Partager

Partager