Discussion :

[fredmn]

Bonjour a tous,

je me pose la question de la pertinence de la déclaration des méthodes en private. Je comprends bien les arguments d'encapsulation qui conduisent à ne déclarer public que les choses réellement importantes (effet boite noire). Mais franchement, il y a de nombreux cas ou le travail accompli dans une méthode private peut-être utile.

Je sais que dans ce cas, il est possible par héritage d'exploiter la méthode private. Mais si l'on considère les langages de scripts, de plus en plus populaires, qui permettent d'exploiter une librairie donnée, certains ne permettent pas l'héritage. On est réduit donc dans ce cas à faire un mix (inutile) de java-langage de script, simplement pour écrire une classe bidon.

Je pose donc la question : est-il réellement utile de déclarer des méthodes private, avec la tendance script de la jvm ?

[fr1man]

Oui si on veut pas que cette méthode soit visible de l'extérieur, comme tu l'as bien compris.
Je pense tout de suite à l'exemple du pattern singleton qui déclare un constructeur privé, pour ne pas permettre la création d'instances.

[fredmn]

ok, mais qu'est ce qui peut "réellement " justifier une telle invisibilité ?

Imaginons une librairie open-source, donc avec une volonté de partage du code. Est-ce cohérent de mettre des méthodes private dans cette librairie, ce qui va empécher leur utilisation éventuelle ?

[adiGuba]

Salut,

ok, mais qu'est ce qui peut "réellement " justifier une telle invisibilité ?

Imaginons une librairie open-source, donc avec une volonté de partage du code.

La visibilité des attributs/méthodes n'a rien à voir avec une éventuelle licence open-source ou autre...

La visibilité permet de cacher des attributs/méthodes qui serait directement inutile par les utilisateurs de la classe.


a++

PS : et une méthode private ne peut pas être utilisé via un héritage...

[franck06]

Bonjour a tous,

je me pose la question de la pertinence de la déclaration des méthodes en private. Je comprends bien les arguments d'encapsulation qui conduisent à ne déclarer public que les choses réellement importantes (effet boite noire). Mais franchement, il y a de nombreux cas ou le travail accompli dans une méthode private peut-être utile.

Je sais que dans ce cas, il est possible par héritage d'exploiter la méthode private. Mais si l'on considère les langages de scripts, de plus en plus populaires, qui permettent d'exploiter une librairie donnée, certains ne permettent pas l'héritage. On est réduit donc dans ce cas à faire un mix (inutile) de java-langage de script, simplement pour écrire une classe bidon.

Je pose donc la question : est-il réellement utile de déclarer des méthodes private, avec la tendance script de la jvm ?

dans ce cas la, est-il utile d'utilliser le protected ?
pourquoi ne pas mettre des public partout ?

ca c'est la reponse a cette question d'un prof que j'ai eu en fac :
les mots cles, c'est pour dans ta tete, public partout c'est pareil ...

[fredmn]

1. C'est justement le point qui me chagrine : comment quelqu'un peut-il savoir que la méthode m'est inutile ? Il se trouve que je suis justement dans le cas où une méthode me serait utile, mais je ne peut y accéder.

2. Je trouve au contraire le lien avec l'open-source pertinent. Quel interet à publier une librairie en open-source, si c'est pour interdire l'utilisation de certaines méthodes. Je trouve cela contradictoire dans les intentions.

ps : si en plus, je n'y ai même pas accès en private, j'ai franchement du mal à comprendre.

[adiGuba]

1. C'est justement le point qui me chagrine : comment quelqu'un peut-il savoir que la méthode m'est inutile ? Il se trouve que je suis justement dans le cas où une méthode me serait utile, mais je ne peut y accéder.

Le mieux serait que tu décrives le problème que tu rencontres...

2. Je trouve au contraire le lien avec l'open-source pertinent. Quel interet à publier une librairie en open-source, si c'est pour interdire l'utilisation de certaines méthodes. Je trouve cela contradictoire dans les intentions.

Encore une fois cela n'a rien à voir avec l'open-source.
Si la méthode est private c'est que le développeur considère qu'il s'agit de traitement interne dont les utilisateurs de la classe ne devront pas utiliser directement...

ps : si en plus, je n'y ai même pas accès en private, j'ai franchement du mal à comprendre.

private = accès interdit

a++

[fredmn]

Effectivement, comme je vois que l'on ne se comprend pas, je décris mon problème.

Je travaille avec ImageJ, une plateforme qui permet de faire du traitement d'image. ImageJ s'utilise avec un système de plugin qui effectue certains traitements. Les plugins sont codés sous forme de classes.
Mon objectif est de réaliser un plugin qui exploite une fft. Il se trouve qu'il existe un plugin fft, que je peux appeler mais qui est bouré d'effet de bord non-désiré (affichage d'images entre autres). Je désire donc calculer une fft mais je ne peut utiliser les méthodes publique du plugin qui me produise ces effets indésirables.

En fouillant dans le code du plugin, je constate qu'il existe des méthodes qui calculent la fft, mais comme elle sont déclarées private, je ne peut y accéder. La seule méthode publique est celle qui est pleine d'effet de bord.

[Uther]

Le cas de ton plugin est un parfait exemple de l'intérêt de l'encapsulation. Pour l'auteur du plugin, la seule méthode dont le fonctionnement doit être garantit pour l'extérieur est la méthode public. La méthode faisant la FFT est une méthode interne qui ne fait pas partie des services que le plugin fournis.
Supposons que l'auteur modifie son plugin pour qu'il arrive au même résultat sans avoir recourt a une FFT. Il peut supprimer cette méthode sans se demander si elle manquera à quelqu'un : c'est une méthode private.

private n'a pas de notion de libre accès au code source, il permet de délimiter les zone d'action de chaque objet. Si on ne fait pas attention a la conception a ce qui doit être accessible de l'extérieur ou non, on peut arriver a des cas ou tout dépend de tout, et dès que l'on touche quelque-chose, plus rien ne marche.

Il est possible via l'introspection de briser cette limitation, mais je ne le conseille pas. Si le code est libre, il te suffit de le reprendre dans ta propre méthode avec les accès que tu souhaites.

[fredmn]

Le cas de ton plugin est un parfait exemple de l'intérêt de l'encapsulation. Pour l'auteur du plugin, la seule méthode dont le fonctionnement doit être garantit pour l'extérieur est la méthode public. La méthode faisant la FFT est une méthode interne qui ne fait pas partie des services que le plugin fournis.
Supposons que l'auteur modifie son plugin pour qu'il arrive au même résultat sans avoir recourt a une FFT. Il peut supprimer cette méthode sans se demander si elle manquera à quelqu'un : c'est une méthode private.

Dans ce cas particulier, il ne pourra jamais supprimer la fft de son plugin, puisque le plugin calcule et affiche une fft. Ce qui me gène c'est que je ne peux pas calculer la fft, sans l'afficher.

private n'a pas de notion de libre accès au code source, il permet de délimiter les zone d'action de chaque objet. Si on ne fait pas attention, on peut arriver a des cas ou tout dépend de tout, et dès que l'on touche quelquechose, tout s'arrête de marcher.

Bon. Je sens bien que je ne touche personne sur le parallèle entre code open-source et méthode private, donc je laisse tomber.

Il est possible via l'introspection de briser cette limitation, mais je ne le conseille pas. Si le code est libre, il te suffit de le reprendre dans ta propre méthode avec les accès que tu souhaites.

Donc c'est bien l'objet de mon questionnement, impossible de réutiliser cette fonctionnalité sans recopier le code source et donc m'obliger à réécrire du code déja écrit. Je suis désolé mais je ne peux m'empécher de considérer que cela est du temps perdu.

[Morbo]

Ce n'est pas parce qu'un développeur en particulier à mal choisi les méthodes qu'il voulait exposer que le principe l'encapsulation perds son intérêt.

Et même dans ce cas particulier, j'imagine que code java de la fft est suffisamment répandu pour ce développeur n'est pas jugé utile de l'exposer dans son API.

Le fait de ne pas exposer toutes les méthodes de ses classes permet au développeur de s'assurer que ses méthodes de classe ne seront pas appellées n'importe comment et dans n'importe quel ordre.
Et du coté de l'utilisateur de cette classe, ça lui évite d'avoir à se soucié justement de ces détails d'implémentation.

[fredmn]

Ce n'est pas parce qu'un développeur en particulier à mal choisi les méthodes qu'il voulait exposer que le principe l'encapsulation perds son intérêt.

Ben si justement, quant cela empeche tout autre fonctionnement.

Et du coté de l'utilisateur de cette classe, ça lui évite d'avoir à se soucié justement de ces détails d'implémentation.

On peut aussi considérer que l'utilisateur est un grand garçon et qu'il peut être assez grand pour assumer les conséquences de ses actes, du moment que la façon d'appeler "officielle" est bien décrite.

[millie]

Dans ce cas particulier, il ne pourra jamais supprimer la fft de son plugin, puisque le plugin calcule et affiche une fft. Ce qui me gène c'est que je ne peux pas calculer la fft, sans l'afficher.

Pas vraiment, un plugin pour ImageJ est à voir comme une boite noire où le seul point d'entrée et de sortie servent pour ImageJ uniquement.
Il n'y a pas à exposer d'autres méthodes car le plugin doit être uniquement utilisé au sein d'ImageJ, et rien ne garantit les résultats si on court-circuite le plugin.


Il pourrait y avoir des comportements indésirés dans le cas d'appel à une méthode public fft :
- non recentrage de l'image
- utilisation de cache pour optimiser le plan d'exécution (la fft est calculée plusieurs fois)
- l'appel à la fft nécessite éventuellement l'initialisation d'un contexte que tu ne peux pas maitriser


Par contre, rien ne t'empêche de reprendre les sources... Car rien ne l'aurait empêcher de sortir le vrai traitement métier du plugin... Mais il fallait que ce soit concu pour.

[fredmn]

Pas vraiment, un plugin pour ImageJ est à voir comme une boite noire où le seul point d'entrée et de sortie servent pour ImageJ uniquement.
Il n'y a pas à exposer d'autres méthodes car le plugin doit être uniquement utilisé au sein d'ImageJ, et rien ne garantit les résultats si on court-circuite le plugin.

Mais je suis sous ImageJ ! Mon seul objectif d'écrire un plugin qui calcule une fft en (pseudo) temps réel sur un flux vidéo en entrée (a des fins de démonstration). Je veux donc utiliser la fonctionnalité du plugin mais sans l'affichage parasite car je dois calculer plusieurs fft par seconde.

Il pourrait y avoir des comportements indésirés dans le cas d'appel à une méthode public fft :
- non recentrage de l'image
- utilisation de cache pour optimiser le plan d'exécution (la fft est calculée plusieurs fois)
- l'appel à la fft nécessite éventuellement l'initialisation d'un contexte que tu ne peux pas maitriser

La dessus, je suis d'accord. Mais la seule question que je me pose est : pourquoi m'interdire aussi irrémédiablement la chose.

[Vivian Pennel]

Perso je connais pas imageJ ma réponse se contente donc d'un point de vue objet.

La philosophie open source concerne la libre circulation du code source. Ainsi si un jour dans une méthode quelconque (même private) un bug est découvert, "n'importe qui" peut le corriger en allant modifier la méthode incriminé.
Ca c'est l'application en elle même.

Ensuite il y a l'utilisation de l'application ou plutôt de l'API.
Une API est une interface qui permet à une personne qui n'a aucune connaissance de l'implémentation de l'application d'utiliser des services fournis par cette interface.

Prenons un exemple : l'application contient une classe Image qui s'occupe de redimensionner une image. L'application contient une méthode publique "redimensionnerImage(hauteur,largeur)". C'est le service qu'elle propose.
Après dans la classe Image il y aura peut-être une méthode privée (ou N) qui vont s'occuper de faire les calculs, de choisir comment redimensionner etc..
Et ceci c'est l'implémentation, et ca l'utilisateur de l'API n'a aucunement besoin de savoir comment cela se fait, tout ce qu'il veut c'est redimensionner son image.

[fredmn]

Prenons un exemple : l'application contient une classe Image qui s'occupe de redimensionner une image. L'application contient une méthode publique "redimensionnerImage(hauteur,largeur)". C'est le service qu'elle propose.
Après dans la classe Image il y aura peut-être une méthode privée (ou N) qui vont s'occuper de faire les calculs, de choisir comment redimensionner etc..
Et ceci c'est l'implémentation, et ca l'utilisateur de l'API n'a aucunement besoin de savoir comment cela se fait, tout ce qu'il veut c'est redimensionner son image.

Le cas qui m'intéresse et qui a provoqué mon interrogation serait plutôt similaire à celui-ci :

- une méthode publique : redimensionnerImage(échelle)
- une méthode privée : redimensionnerImage(hauteur, largeur)

(avec bien évidemment la méthode redimmensionnerImage(échelle) qui appelle redimmensionnerImage(hauteur, largeur))

conséquence : je ne peut donc appeler redimensionnerImage(hauteur, largeur) alors que c'est exactement ce dont j'aurais besoin.

ps : j'ai bien conscience que mon interrrogation bouscule l'idéologie objet, mais je le redis, cela me chiffonne de retaper du code déja existant.
pps : merci en tout cas aux personnes qui prennent du temps pour discuter.

[Djobird]

Une API est un outil qui te permet d'effectuer des traitements. Si le traitement de prendre en entré une image, et d'afficher en sortie cette image traitée par fft, alors seules les méthodes permettant de proposer cette affichage doivent être public.

Il s'avère que dans ton cas, oui ca aurait été cool d'avoir directement la méthode qui calcul le FFT en public. Mais la spéc de cette API c'est d'afficher une image transformer, pas de calculer une transformer, donc il n'y a pas de raison de mettre public les fonctions de calculs. Peut être que la spec est mal faite, mais ce n'est pas le principe d'encapsulation qui est en cause.

Alors tu vas me dire, mais qu'est ce qui empêchait le type de mettre public la méthode de calcul. Il est possible (je ne fais que supposer) que la façon dont il l'a implémenté faisait que la fonction utilisait des variables qui sont initialisés ailleurs. Après peut être que d'avoir implémenter cette fonction de la sorte est une erreur de conception, j'en sais rien.


Edit : Pour ton exemple, oui en effet ca serait con de faire ca, s'il y'en a une mettre public c'est la 2ème. mais c'est parce qu'il y' a des exemples qui font que c'est con que le principe est mauvais

[Kanithael]

l'API est peut-être mal faite, pas pratique, buggée, inadaptée?... Mais ça reste propre au principe de l'API...

A titre personnel, si dans mes projets on devait mettre toutes nos méthodes public, on ne s'en sortirait pas !! Une API a des objectifs fonctionnels et seuls ces méthodes fonctionnelles doivent apparaitre...

Ils ont raison tous, moi je me moque de savoir comment le traitement est fait, et je n'ai pas envie d'y avoir accès !
C'est aussi une question de lisibilité, de clarté, et donc de simplicité.

[fredmn]

Bon histoire de provoquer un peu, mais on discute entre nous hein ;o)

Il s'avère que dans ton cas, oui ca aurait été cool d'avoir directement la méthode qui calcul le FFT en public. Mais la spéc de cette API c'est d'afficher une image transformer, pas de calculer une transformer, donc il n'y a pas de raison de mettre public les fonctions de calculs. Peut être que la spec est mal faite, mais ce n'est pas le principe d'encapsulation qui est en cause.

Pour autant que je me souvienne, le but de l'objet est de permettre la réutilisation des choses non? Si le fait d'utiliser "trop" d'encapsulation conduit à la possibilité de specs mal faite (dans le sens dont j'ai parlé précedemment), alors le principe de l'encapsulation est-il bon ? Ou pour moduler un peu, peut-être ne faut-il pas trop encapsuler ?

Ils ont raison tous, moi je me moque de savoir comment le traitement est fait, et je n'ai pas envie d'y avoir accès !
C'est aussi une question de lisibilité, de clarté, et donc de simplicité.

Mouais, enfin a quoi cela sert-il d'avoir une api super-claire si au final on la bride ? Parce que au final, je suis aller chercher un tierce librairie, un peu rageant alors que tout est la au départ, potentiellement.

[adiGuba]

A titre personnel, si dans mes projets on devait mettre toutes nos méthodes public, on ne s'en sortirait pas !! Une API a des objectifs fonctionnels et seuls ces méthodes fonctionnelles doivent apparaitre...

Et surtout un gain d'évolutivité !

Les méthodes privées ont un énorme avantage : on peut en faire ce qu'on veut sans que cela impacte QUE notre code !

A l'inverse toute modification sur la signature d'une méthode non-privé pourrait avoir d'importante conséquence sur toutes les classes qui hériteraient ou utiliseraient notre classe. En clair cela aboutit à une incompatibilité potentielle (source, binaire ou les deux selon les cas), ce qui au sein d'une librairie peut poser problème...

Pour autant que je me souvienne, le but de l'objet est de permettre la réutilisation des choses non?

Oui : les objets fournissent un service dont tu peux te servir. Mais tu n'as pas forcément à connaitre la manière dont ils travaillent et encore moins à t'immiscer là dedans !

Si la moindre classe devrait fournir publiquement le moindre code qu'elle utiles, on se retrouverait avec des classes énormes surchargés de méthodes inutilisé dans 99% des cas...


a++